Exportation de données de migration à partir de .com

1. Vérifiez que vous disposez d’autorisations de propriétaire sur les dépôts de l’organisation source.

2. Générer un jeton d'accès avec les champs d'application repo et admin:org sur .com.

3. Pour réduire le temps d’arrêt, créez une liste de dépôts que vous souhaitez exporter à partir de l’instance source. Vous pouvez ajouter plusieurs dépôts à la fois à une exportation à l’aide d’un fichier texte qui liste l’URL de chaque dépôt sur une ligne distincte.

Pour exporter des données de dépôt à partir de .com, utilisez l’API Migrations.

L’API Migrations est actuellement en préversion, ce qui signifie que les points de terminaison et les paramètres peuvent changer.

1. Informez les membres de votre organisation que vous allez effectuer une migration. L’exportation peut prendre plusieurs minutes, selon le nombre de dépôts exportés. La migration complète, importation incluse, peut prendre plusieurs heures. Nous vous recommandons donc d’effectuer un essai pour déterminer la durée du processus complet. Pour plus d’informations, consultez « À propos de ghe-migrator ».

2. Démarrez une migration en envoyant une requête POST au point de terminaison de la migration. Vous devez disposer des éléments suivants :

   • Votre jeton d’accès pour l’authentification.

   • Une liste des dépôts que vous souhaitez migrer :

     curl -H "Authorization: Bearer _ACCESS_TOKEN" \
     -X POST \
     -H "Accept: application/vnd.+json" \
     -d'{"lock_repositories":true,"repositories":["ORG_NAME/REPO_NAME", "ORG_NAME/REPO_NAME"]}' \
     https://api..com/orgs/ORG_NAME/migrations
     

   • Si vous souhaitez verrouiller les dépôts avant de les migrer, vérifiez que lock_repositories est défini sur true. Cette vérification est fortement recommandée.

   • Vous pouvez exclure les fichiers joints en passant exclude_attachments: true au point de terminaison. Les fichiers joints peuvent être volumineux et risquent d'alourdir inutilement votre archive de migration finale. La taille finale de l’archive doit être inférieure à 20 Go.

   Cette requête retourne un id unique qui représente votre migration. Vous en aurez besoin pour les appels suivants à l’API Migrations.

3. Envoyez une requête GET au point de terminaison d’état de migration pour récupérer l’état d’une migration. Vous devez disposer des éléments suivants :

   • Votre jeton d’accès pour l’authentification.

   • L’id unique de la migration :

     curl -H "Authorization: Bearer _ACCESS_TOKEN" \
     -H "Accept: application/vnd.+json" \
     https://api..com/orgs/ORG_NAME/migrations/ID
     

   Une migration peut avoir l’un des états suivants :

   • pending : la migration n’a pas encore démarré.
   • exporting : la migration est en cours.
   • exported : la migration s’est terminée correctement.
   • failed : la migration a échoué.

4. Après l’exportation de votre migration, téléchargez l’archive de migration en envoyant une requête GET au point de terminaison de téléchargement de la migration. Vous devez disposer des éléments suivants :

   • Votre jeton d’accès pour l’authentification.

   • L’id unique de la migration :

     curl -H "Authorization: Bearer _ACCESS_TOKEN" \
     -H "Accept: application/vnd.+json" \
     -L -o migration_archive.tar.gz \
     https://api..com/orgs/ORG_NAME/migrations/ID/archive
     

5. L’archive de migration est automatiquement supprimée au bout de sept jours. Si vous préférez la supprimer plus tôt, vous pouvez envoyer une requête DELETE au point de terminaison de suppression de l’archive de migration. Vous devez disposer des éléments suivants :

   • Votre jeton d’accès pour l’authentification.

   • L’id unique de la migration :

     curl -H "Authorization: Bearer _ACCESS_TOKEN" \
     -X DELETE \
     -H "Accept: application/vnd.+json" \
     https://api..com/orgs/ORG_NAME/migrations/ID/archive
     

6. Pour préparer les données de migration archivées à importer dans une instance Enterprise Server, consultez Migration de données vers Enterprise Server.