Skip to main content

Migration de dépôts de GitHub Enterprise Server vers GitHub Enterprise Cloud

Vous pouvez migrer des dépôts de GitHub Enterprise Server vers GitHub Enterprise Cloud en utilisant GitHub CLI ou l’API.

Tool navigation

À propos des migrations de dépôts avec GitHub Enterprise Importer

Vous pouvez exécuter votre migration avec GitHub CLI ou l’API.

GitHub CLI simplifie le processus de migration et est recommandé pour la plupart des clients. Les clients avancés avec de grands besoins de personnalisation peuvent utiliser l’API pour créer leurs propres intégrations avec GitHub Enterprise Importer.

Si vous choisissez d’utiliser l’API, vous devrez écrire vos propres scripts ou utiliser un client HTTP comme Insomnia. Pour bien démarrer avec les API de GitHub, consultez « Prise en main de l’API REST » et « Formation d’appels avec GraphQL ».

Pour migrer vos dépôts de GitHub Enterprise Server vers GitHub Enterprise Cloud avec les API, vous devez :

  1. Créer un personal access token pour les organisations source et de destination
  2. Récupérer le ownerId de l’organisation de destination sur GitHub Enterprise Cloud
  3. Configurer une source de migration via l’API GraphQL de GitHub.com pour identifier l’emplacement d’origine de la migration
  4. Pour chaque dépôt que vous souhaitez migrer, répétez ces étapes.
    • Utiliser l’API REST sur votre instance GitHub Enterprise Server pour générer des archives de migration pour votre dépôt
    • Charger vos archives de migration dans un emplacement accessible à GitHub.com
    • Démarrer votre migration à l’aide de l’API GraphQL pour GitHub.com en passant vos URL d’archive
    • Vérifier l’état de votre migration via l’API GraphQL
    • Valider votre migration et consulter le journal des erreurs

Pour voir les instructions d’utilisation de l’API, utilisez le sélecteur d’outils en haut de la page.

Pour voir les instructions d’utilisation de GitHub CLI, utilisez le sélecteur d’outils en haut de la page.

Prérequis

  • Pour veiller à bien comprendre les limitations connues du support de l’importateur, consultez « À propos de GitHub Enterprise Importer ».
  • Nous vous recommandons vivement d’effectuer une exécution d’essai de votre migration et d’effectuer votre migration de production peu après. Pour en savoir plus sur les bonnes pratiques relatives aux exécutions d’essai, consultez « Préparation à l’exécution d’une migration avec GitHub Enterprise Importer ».
  • Bien que cela ne soit pas obligatoire, nous vous recommandons d’interrompre votre travail pendant votre migration de production. Importer ne prend pas en charge les migrations delta, donc aucune modification apportée pendant la migration ne sera migrée. Si vous choisissez de ne pas interrompre le travail pendant votre migration de production, vous devrez migrer manuellement ces modifications.
  • Vous devez être propriétaire d’organisation ou recevoir le rôle de migrateur pour les organisations source et de destination. Pour plus d’informations, consultez « Octroi du rôle de migrateur pour GitHub Enterprise Importer ».
  • Si vous utilisez GitHub Enterprise Server 3.8 ou ultérieur, vous devez avoir accès à la Management Console.

Étape 1. Créer votre personal access token

  1. Créez et enregistrez un personal access token qui servira d’authentification pour l’organisation de destination sur GitHub Enterprise Cloud, en vous assurant qu’il répond à toutes les exigences. Pour plus d’informations, consultez « Gestion de l’accès pour GitHub Enterprise Importer ».
  2. Créez et enregistrez un personal access token qui servira d’authentification pour l’organisation source, en vous assurant qu’il répond également aux mêmes exigences.

Étape 2 : Obtenir le ownerId pour l’organisation de destination

En tant que propriétaire de l’organisation dans GitHub Enterprise Cloud, utilisez la requête GetOrgInfo pour retourner l’ownerId, également appelé ID d’organisation, pour l’organisation dont vous souhaitez posséder les dépôts migrés. Vous aurez besoin de l’ownerId pour identifier votre destination de migration.

Requête GetOrgInfo

query(
  $login: String!
){
  organization (login: $login)
  {
    login
    id
    name
    databaseId
  }
}
Variable de requêteDescription
loginNom de votre organisation.

Réponse GetOrgInfo

{
  "data": {
    "organization": {
      "login": "Octo",
      "id": "MDEyOk9yZ2FuaXphdGlvbjU2MTA=",
      "name": "Octo-org",
      "databaseId": 5610
    }
  }
}

Dans cet exemple, MDEyOk9yZ2FuaXphdGlvbjU2MTA= est l’ID d’organisation ou le ownerId, que nous utiliserons à l’étape suivante.

Étape 3 : Configurer le stockage d’objets blob

De nombreuses instances GitHub Enterprise Server se trouvant derrière des pare-feux, pour GitHub Enterprise Server version 3.8 ou ultérieure, nous utilisons le stockage d’objets blob comme emplacement intermédiaire pour stocker les données auxquelles GitHub peut accéder.

Vous devez d’abord configurer le stockage d’objets blob avec un fournisseur de cloud pris en charge, puis configurer vos paramètres dans la Management Console de votre instance GitHub Enterprise Server.

Remarque : Vous avez seulement besoin de configurer le stockage d’objets blob si vous utilisez GitHub Enterprise Server version 3.8 ou ultérieure. Si vous utilisez GitHub Enterprise Server version 3.7 ou antérieure, passez à « Étape 4 : Configurer une source de migration dans GitHub Enterprise Cloud ».

Le stockage d’objets blob est nécessaire pour migrer des dépôts avec une source Git ou des métadonnées volumineuses. Si vous utilisez GitHub Enterprise Server version 3.7 ou antérieure, vous ne pourrez pas effectuer de migrations si vos exportations de source Git ou de métadonnées dépassent 2 Go. Pour mener à bien ces migrations, effectuez la mise à jour vers GitHub Enterprise Server version 3.8 ou ultérieure.

Configuration du stockage d’objets blob avec un fournisseur de cloud pris en charge

GitHub CLI prend en charge les fournisseurs de stockage de blobs suivants :

  • Amazon Web Services (AWS) S3
  • Stockage Blob Azure

Configuration d’un compartiment de stockage AWS S3

Dans AWS, configurez un compartiment S3. Pour plus d’informations, consultez Créer un compartiment dans la documentation AWS.

Vous aurez également besoin d’une clé d’accès AWS et d’une clé secrète avec les autorisations suivantes :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucketMultipartUploads",
                "s3:AbortMultipartUpload",
                "s3:ListBucket",
                "s3:DeleteObject",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": [
                "arn:aws:s3:::github-migration-bucket",
                "arn:aws:s3:::github-migration-bucket/*"
            ]
        }
    ]
}

Remarque : GitHub Enterprise Importer ne supprime pas votre archive d’AWS une fois votre migration terminée. Pour réduire les coûts de stockage, nous vous recommandons de configurer la suppression automatique de votre archive après une certaine période. Pour plus d’informations, consultez Définition d’une configuration de cycle de vie sur un compartiment dans la documentation AWS.

Configuration d’un compte Stockage Blob Azure

Dans Azure, créez un compte de stockage et notez votre chaîne de connexion. Pour plus d’informations, consultez Gérer les clés d’accès au compte de stockage dans Microsoft Docs.

Remarque : GitHub Enterprise Importer ne supprime pas votre archive du Stockage Blob Azure une fois votre migration terminée. Pour réduire les coûts de stockage, nous vous recommandons de configurer la suppression automatique de votre archive après une certaine période. Pour plus d’informations, consultez Optimiser les coûts en gérant automatiquement le cycle de vie des données dans Microsoft Docs.

Configuration du stockage d’objets blob dans la Management Console de votre instance GitHub Enterprise Server

Après avoir configuré un compartiment de stockage AWS S3 ou un compte Stockage Blob Azure, configurez le stockage de blobs dans la Management Console de votre instance GitHub Enterprise Server. Pour plus d’informations sur la Management Console, consultez « Administration de votre instance à partir de la console de gestion ».

  1. À partir d’un compte d’administration sur GitHub Enterprise Server, cliquez sur en haut à droite de n’importe quelle page.

  2. Si vous n’êtes pas déjà sur la page « Administrateur du site », dans le coin supérieur gauche, cliquez sur Administrateur du site. 1. Dans la barre latérale «  Administrateur de site », cliquez sur Management Console .

  3. Connectez-vous à la Management Console.

  4. Dans la barre de navigation supérieure, cliquez sur Paramètres.

  5. Sous Migrations, cliquez sur Activer les migrations GitHub .

  6. Si vous le souhaitez, pour importer les paramètres de stockage que vous avez configurés pour GitHub Actions, sélectionnez Copier les paramètres de stockage dans Actions. Pour plus d’informations, consultez « Activation de GitHub Actions avec le Stockage Blob Azure » et « Activation de GitHub Actions avec le stockage Amazon S3 ».

  7. Si vous n’importez pas les paramètres de stockage à partir de GitHub Actions, sélectionnez Stockage Blob Azure ou Amazon S3 et renseignez les détails requis.

    Note : Si vous utilisez Amazon S3, vous devez définir « AWS Service URL » (URL du service AWS) sur le point de terminaison standard pour la région AWS où se trouve votre compartiment. Par exemple, si votre compartiment se trouve dans la région eu-west-1, « AWS Service URL » (URL du service AWS) est https://s3.eu-west-1.amazonaws.com. Le réseau de votre instance GitHub Enterprise Server doit autoriser l’accès à cet hôte. Les points de terminaison de passerelle ne sont pas pris en charge, tels que bucket.vpce-0e25b8cdd720f900e-argc85vg.s3.eu-west-1.vpce.amazonaws.com. Pour plus d’informations sur les points de terminaison de passerelle, consultez Points de terminaison de passerelle pour Amazon S3 dans la documentation AWS.

  8. Cliquez sur Tester les paramètres de stockage.

  9. Cliquez sur Enregistrer les paramètres.

Étape 4 : Configurer une source de migration dans GitHub Enterprise Cloud

Vous pouvez configurer une source de migration à l’aide de la requête createMigrationSource. Vous devez fournir l’ownerId, ou l’ID d’organisation, collecté à partir de la requête GetOrgInfo.

La source de votre migration est votre organisation sur GitHub Enterprise Server.

Mutation createMigrationSource

mutation createMigrationSource($name: String!, $url: String!, $ownerId: ID!) {
  createMigrationSource(input: {name: $name, url: $url, ownerId: $ownerId, type: GITHUB_ARCHIVE}) {
    migrationSource {
      id
      name
      url
      type
    }
  }
}

Remarque : Veillez à utiliser GITHUB_ARCHIVE pour type.

Variable de requêteDescription
nameNom pour votre source de migration. Ce nom est juste pour vous, donc vous pouvez utiliser n’importe quelle chaîne.
ownerIdID d’organisation de votre organisation sur GitHub Enterprise Cloud.
urlURL de votre instance GitHub Enterprise Server. Cette URL n’a pas besoin d’être accessible à partir de GitHub Enterprise Cloud.

Réponse createMigrationSource

{
  "data": {
    "createMigrationSource": {
      "migrationSource": {
        "id": "MS_kgDaACRjZTY5NGQ1OC1mNDkyLTQ2NjgtOGE1NS00MGUxYTdlZmQwNWQ",
        "name": "GHES Source",
        "url": "https://my-ghes-hostname.com",
        "type": "GITHUB_ARCHIVE"
      }
    }
  }
}

Dans cet exemple, MS_kgDaACRjZTY5NGQ1OC1mNDkyLTQ2NjgtOGE1NS00MGUxYTdlZmQwNWQ est l’ID de la source de la migration. Nous l’utiliserons dans une étape ultérieure.

Étape 5 : Générer des archives de migration sur votre instance GitHub Enterprise Server

Vous allez utiliser l’API REST pour démarrer deux « migrations » dans GitHub Enterprise Server : une pour générer une archive de la source Git de votre dépôt et une pour générer une archive des métadonnées (comme les problèmes et les demandes de tirage) de votre dépôt.

Pour générer l’archive de la source Git, envoyez une demande POST à https://HOSTNAME/api/v3/orgs/ORGANIZATION/migrations, en remplaçant HOSTNAME par le nom d’hôte de votre instance GitHub Enterprise Server et ORGANIZATION par l’identifiant de connexion de votre organisation.

Dans le corps, spécifiez le dépôt unique que vous souhaitez migrer. Votre demande doit ressembler à ceci :

POST /api/v3/orgs/acme-corp/migrations HTTP/1.1
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
Content-Type: application/json
Host: github.acmecorp.net

{
  "repositories": ["repository_to_migrate"],
  "exclude_metadata": true
}

Pour générer une archive de vos métadonnées, envoyez une demande similaire à la même URL avec le corps suivant :

{
  "repositories": ["repository_to_migrate"],
  "exclude_git_data": true,
  "exclude_releases": false,
  "exclude_owner_projects": true
}

Chacun de ces appels d’API retourne une réponse JSON comprenant l’ID de la migration que vous avez démarrée.

HTTP/1.1 201 Created

{
  "id": 123,
  // ...
}

Pour plus d’informations, consultez « Démarrer une migration d’organisation » dans la documentation de l’API REST.

En fonction de la quantité de données, la génération des archives peut prendre un certain temps. Vous pouvez vérifier régulièrement l’état des deux migrations avec l’API « Obtenir l’état d’une migration d’organisation », jusqu’à ce que l’état (state) de la migration passe à exported.

GET /api/v3/orgs/acme-corp/migrations/123 HTTP/1.1
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
Host: github.acmecorp.net

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 123,
  "state": "exported",
  // ...
}

Pour plus d’informations, consultez « Obtenir l’état d’une migration d’organisation » dans la documentation de l’API REST.

Remarque : Si votre migration passe à l’état failed à la place de l’état exported, essayez de relancer la migration. Si la migration échoue à plusieurs reprises, nous vous recommandons de générer les archives en utilisant ghe-migrator au lieu de l’API.

Effectuez les étapes décrites dans « Exportation des données de migration de votre entreprise », en ajoutant un seul dépôt à la migration. À la fin du processus, vous disposerez d’une archive de migration unique avec votre source Git et vos métadonnées, et vous pourrez passer à l’étape 6 de cet article.

Quand l’état (state) d’une migration passe à exported, vous pouvez récupérer l’URL de la migration à l’aide de l’API « Télécharger une archive de migration d’organisation ».

GET /api/v3/orgs/acme-corp/migrations/123/archive HTTP/1.1
Accept: application/vnd.github+json
Authorization: Bearer <TOKEN>
Host: github.acmecorp.net

HTTP/1.1 302 Found
Location: https://media.github.acmecorp.net/migrations/123/archive/cca2ebe9-7403-4ffa-9b6a-4c9e16c94410?token=AAAAABEWE7JP4H2HACKEGMTDOYRC6

L’API retourne une réponse 302 Found avec un en-tête Location qui redirige vers l’URL où se trouve l’archive téléchargeable. Téléchargez les deux fichiers : un pour la source Git et un pour les métadonnées.

Pour plus d’informations, consultez « Télécharger une archive de migration d’organisation » dans la documentation de l’API REST.

Une fois les deux migrations terminées et les archives téléchargées, vous pouvez passer à l’étape suivante.

Étape 6 : Charger vos archives de migration

Pour importer vos données dans GitHub Enterprise Cloud, vous devez passer les deux archives de chaque dépôt (source Git et métadonnées) de votre ordinateur à GitHub.com, à l’aide de notre API GraphQL.

Si vous utilisez GitHub Enterprise Server 3.7 ou antérieur, vous devez d’abord générer des URL pour les archives accessibles à GitHub.com. La plupart des clients choisissent de charger les archives sur le service de stockage d’objets blob d’un fournisseur de cloud, comme Amazon S3 ou Stockage Blob Azure, puis de générer une URL à courte durée de vie pour chaque archive.

Si vous utilisez GitHub Enterprise Server 3.8 ou ultérieur, votre instance charge les archives et génère les URL pour vous. L’en-tête Location de l’étape précédente retourne l’URL à courte durée de vie.

Vous devrez peut-être établir une liste d’autorisation des plages d’adresses IP de GitHub. Pour plus d’informations, consultez « Gestion de l’accès pour GitHub Enterprise Importer ».

Étape 7 : Démarrer la migration de votre dépôt

Lorsque vous démarrez une migration, un seul dépôt et ses données associées migrent vers un tout nouveau dépôt GitHub que vous identifiez.

Si vous souhaitez déplacer plusieurs dépôts à la fois de la même organisation source, vous pouvez mettre en file d’attente plusieurs migrations. Vous pouvez exécuter jusqu’à 5 migrations de dépôt en même temps.

Mutation startRepositoryMigration

mutation startRepositoryMigration (
  $sourceId: ID!,
  $ownerId: ID!,
  $repositoryName: String!,
  $continueOnError: Boolean!,
  $accessToken: String!,
  $githubPat: String!,
  $gitArchiveUrl: String!,
  $metadataArchiveUrl: String!,
  $sourceRepositoryUrl: URI!,
  $targetRepoVisibility: String!
){
  startRepositoryMigration( input: {
    sourceId: $sourceId,
    ownerId: $ownerId,
    repositoryName: $repositoryName,
    continueOnError: $continueOnError,
    accessToken: $accessToken,
    githubPat: $githubPat,
    targetRepoVisibility: $targetRepoVisibility
    gitArchiveUrl: $gitArchiveUrl,
    metadataArchiveUrl: $metadataArchiveUrl,
    sourceRepositoryUrl: $sourceRepositoryUrl,
  }) {
    repositoryMigration {
      id
      migrationSource {
        id
        name
        type
      }
      sourceUrl
    }
  }
}
Variable de requêteDescription
sourceIdid de votre source de migration retournée par la mutation createMigrationSource.
ownerIdID d’organisation de votre organisation sur GitHub Enterprise Cloud.
repositoryNameNom de dépôt unique personnalisé qui n’est actuellement utilisé par aucun de vos dépôts appartenant à l’organisation sur GitHub Enterprise Cloud. Un problème de journalisation des erreurs sera créé dans ce dépôt une fois votre migration terminée ou arrêtée.
continueOnErrorParamètre de migration qui permet à la migration de se poursuivre en cas d’erreurs qui n’entraînent pas l’échec de la migration. Doit être true ou false. Nous vous recommandons vivement de définir continueOnError sur true afin que votre migration continue, sauf si Importer ne peut pas déplacer la source Git ou que Importer a perdu la connexion et ne peut pas se reconnecter pour terminer la migration.
githubPatpersonal access token pour votre organisation de destination sur GitHub Enterprise Cloud. Pour connaître les exigences en termes de personal access token, consultez « Gestion de l’accès pour GitHub Enterprise Importer ».
accessTokenpersonal access token pour votre source.
targetRepoVisibilityVisibilité du nouveau dépôt. Doit être private, public ou internal. Si elle n’est pas définie, votre dépôt est migré avec une visibilité privée.
gitArchiveUrlURL de l’archive de votre source Git accessible à GitHub Enterprise Cloud.
metadataArchiveUrlURL de l’archive de vos métadonnées accessible à GitHub Enterprise Cloud.
sourceRepositoryUrlURL de votre dépôt sur votre instance GitHub Enterprise Server. Elle est obligatoire, mais GitHub Enterprise Cloud ne communique pas directement avec votre instance GitHub Enterprise Server.

À l’étape suivante, vous allez utiliser l’ID de migration retourné par la mutation startRepositoryMigration pour vérifier l’état de la migration.

Étape 8 : Vérifier l’état de votre migration

Pour détecter les échecs de migration et vous assurer que votre migration fonctionne, vous pouvez vérifier l’état de votre migration en utilisant la requête getMigration. Vous pouvez également vérifier l’état de plusieurs migrations avec getMigrations.

La requête getMigration est retournée avec un état pour vous indiquer si la migration est queued, in progress, failed ou completed. Si votre migration a échoué, Importer fournit la raison de l’échec.

Requête getMigration

query (
  $id: ID!
){
  node( id: $id ) {
    ... on Migration {
      id
      sourceUrl
      migrationSource {
        name
      }
      state
      failureReason
    }
  }
}
Variable de requêteDescription
idid de votre migration que la mutation startRepositoryMigration a retourné.

Étape 9 : Valider votre migration et consulter le journal des erreurs

Pour terminer votre migration, nous vous recommandons de consulter le problème « Journal de migration ». Ce problème est créé sur GitHub dans le dépôt de destination.

Capture d’écran d’un problème avec le titre « Journal de migration ». Le deuxième commentaire du problème contient les journaux d’une migration.

Enfin, nous vous recommandons de passer en revue vos dépôts migrés pour en contrôler l’intégrité.

Étape 1 : Installer l’GEI extension of the GitHub CLI

S’il s’agit de votre première migration, vous devez installer GEI extension of the GitHub CLI. Pour plus d’informations sur GitHub CLI, consultez « À propos de GitHub CLI ».

  1. Installez GitHub CLI. Pour obtenir des instructions d’installation pour GitHub CLI, consultez le dépôt GitHub CLI.

    Remarque : Vous devez avoir la version 2.4.0 ou ultérieure de GitHub CLI. Vous pouvez vérifier la version que vous avez installée avec la commande gh --version.

  2. Installez GEI extension.

    Shell
    gh extension install github/gh-gei
    

Dès que vous avez besoin d’aide sur GEI extension, vous pouvez utiliser l’indicateur --help avec une commande. Par exemple, gh gei --help liste toutes les commandes disponibles et gh gei migrate-repo --help liste toutes les options disponibles pour la commande migrate-repo.

Étape 2 : Mettre à jour l’GEI extension of the GitHub CLI

GEI extension est mis à jour toutes les semaines. Pour être sûr d’utiliser la version la plus récente, mettez à jour l’extension.

gh extension upgrade github/gh-gei

Étape 3 : Définir les variables d’environnement

Avant de pouvoir utiliser GEI extension pour migrer vers GitHub Enterprise Cloud, vous devez créer des personal access token qui peuvent accéder aux organisations source et de destination, puis définir les personal access token en tant que variables d’environnement.

  1. Créez et enregistrez un personal access token qui servira d’authentification pour l’organisation de destination sur GitHub Enterprise Cloud, en vous assurant qu’il répond à toutes les exigences. Pour plus d’informations, consultez « Gestion de l’accès pour GitHub Enterprise Importer ».

  2. Créez et enregistrez un personal access token qui servira d’authentification pour l’organisation source, en vous assurant qu’il répond également aux mêmes exigences.

  3. Définissez les variables d’environnement pour les personal access token, en remplaçant TOKEN dans les commandes ci-dessous par les personal access token que vous avez enregistrés ci-dessus. Utilisez GH_PAT pour l’organisation de destination et GH_SOURCE_PAT pour l’organisation source.

    • Si vous utilisez le Terminal, utilisez la commande export.

      Shell
      export GH_PAT="TOKEN"
      export GH_SOURCE_PAT="TOKEN"
      
    • Si vous utilisez PowerShell, utilisez la commande $env.

      Shell
      $env:GH_PAT="TOKEN"
      $env:GH_SOURCE_PAT="TOKEN"
      

Étape 4 : Configurer le stockage d’objets blob

De nombreuses instances GitHub Enterprise Server se trouvant derrière des pare-feux, nous utilisons le stockage d’objets blob comme emplacement intermédiaire pour stocker les données auxquelles GitHub peut accéder.

Pour commencer, vous devez configurer le stockage d’objets blob avec un fournisseur de cloud pris en charge. Ensuite, vous devez configurer vos informations d’identification pour le fournisseur de stockage dans la Management Console ou GitHub CLI.

Configuration du stockage d’objets blob avec un fournisseur de cloud pris en charge

GitHub CLI prend en charge les fournisseurs de stockage de blobs suivants :

  • Amazon Web Services (AWS) S3
  • Stockage Blob Azure

Configuration d’un compartiment de stockage AWS S3

Dans AWS, configurez un compartiment S3. Pour plus d’informations, consultez Créer un compartiment dans la documentation AWS.

Vous aurez également besoin d’une clé d’accès AWS et d’une clé secrète avec les autorisations suivantes :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucketMultipartUploads",
                "s3:AbortMultipartUpload",
                "s3:ListBucket",
                "s3:DeleteObject",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": [
                "arn:aws:s3:::github-migration-bucket",
                "arn:aws:s3:::github-migration-bucket/*"
            ]
        }
    ]
}

Remarque : GitHub Enterprise Importer ne supprime pas votre archive d’AWS une fois votre migration terminée. Pour réduire les coûts de stockage, nous vous recommandons de configurer la suppression automatique de votre archive après une certaine période. Pour plus d’informations, consultez Définition d’une configuration de cycle de vie sur un compartiment dans la documentation AWS.

Configuration d’un compte Stockage Blob Azure

Dans Azure, créez un compte de stockage et notez votre chaîne de connexion. Pour plus d’informations, consultez Gérer les clés d’accès au compte de stockage dans Microsoft Docs.

Remarque : GitHub Enterprise Importer ne supprime pas votre archive du Stockage Blob Azure une fois votre migration terminée. Pour réduire les coûts de stockage, nous vous recommandons de configurer la suppression automatique de votre archive après une certaine période. Pour plus d’informations, consultez Optimiser les coûts en gérant automatiquement le cycle de vie des données dans Microsoft Docs.

Configuration de vos informations d’identification pour le stockage d’objets blob

Après avoir configuré le stockage d’objets blob avec un fournisseur de cloud pris en charge, vous devez configurer vos informations d’identification pour le fournisseur de stockage dans GitHub :

  • Si vous utilisez GitHub Enterprise Server 3.8 ou ultérieur, configurez vos informations d’identification dans la Management Console.
  • Si vous utilisez GitHub Enterprise Server 3.7 ou antérieur, configurez les informations d’identification dans GitHub CLI.

Configuration du stockage d’objets blob dans la Management Console de votre instance GitHub Enterprise Server

Remarque : Vous avez seulement besoin de configurer le stockage d’objets blob dans la Management Console si vous utilisez GitHub Enterprise Server 3.8 ou ultérieur. Si vous utilisez la version 3.7 ou antérieure, configurez vos informations d’identification dans GitHub CLI à la place.

Après avoir configuré un compartiment de stockage AWS S3 ou un compte Stockage Blob Azure, configurez le stockage de blobs dans la Management Console de votre instance GitHub Enterprise Server. Pour plus d’informations sur la Management Console, consultez « Administration de votre instance à partir de la console de gestion ».

  1. À partir d’un compte d’administration sur GitHub Enterprise Server, cliquez sur en haut à droite de n’importe quelle page.

  2. Si vous n’êtes pas déjà sur la page « Administrateur du site », dans le coin supérieur gauche, cliquez sur Administrateur du site. 1. Dans la barre latérale «  Administrateur de site », cliquez sur Management Console .

  3. Connectez-vous à la Management Console.

  4. Dans la barre de navigation supérieure, cliquez sur Paramètres.

  5. Sous Migrations, cliquez sur Activer les migrations GitHub .

  6. Si vous le souhaitez, pour importer les paramètres de stockage que vous avez configurés pour GitHub Actions, sélectionnez Copier les paramètres de stockage dans Actions. Pour plus d’informations, consultez « Activation de GitHub Actions avec le Stockage Blob Azure » et « Activation de GitHub Actions avec le stockage Amazon S3 ».

  7. Si vous n’importez pas les paramètres de stockage à partir de GitHub Actions, sélectionnez Stockage Blob Azure ou Amazon S3 et renseignez les détails requis.

    Note : Si vous utilisez Amazon S3, vous devez définir « AWS Service URL » (URL du service AWS) sur le point de terminaison standard pour la région AWS où se trouve votre compartiment. Par exemple, si votre compartiment se trouve dans la région eu-west-1, « AWS Service URL » (URL du service AWS) est https://s3.eu-west-1.amazonaws.com. Le réseau de votre instance GitHub Enterprise Server doit autoriser l’accès à cet hôte. Les points de terminaison de passerelle ne sont pas pris en charge, tels que bucket.vpce-0e25b8cdd720f900e-argc85vg.s3.eu-west-1.vpce.amazonaws.com. Pour plus d’informations sur les points de terminaison de passerelle, consultez Points de terminaison de passerelle pour Amazon S3 dans la documentation AWS.

  8. Cliquez sur Tester les paramètres de stockage.

  9. Cliquez sur Enregistrer les paramètres.

Configuration de vos informations d’identification pour le stockage d’objets blob dans GitHub CLI

Remarque : Vous avez seulement besoin de configurer vos informations d’identification pour le stockage d’objets blob dans GitHub CLI si vous utilisez GitHub Enterprise Server 3.7 ou antérieur. Si vous utilisez la version 3.8 ou ultérieure, configurez plutôt le stockage d’objets blob dans la Management Console.

Si vous configurez vos informations d’identification pour le stockage d’objets blob dans GitHub CLI, vous ne pourrez pas effectuer de migrations si les exportations de votre source Git ou de vos métadonnées dépassent 2 Go. Pour mener à bien ces migrations, effectuez la mise à niveau vers GitHub Enterprise Server version 3.8 ou ultérieure.

Configuration des informations d’identification AWS S3 dans GitHub CLI

Quand vous êtes prêt à exécuter votre migration, vous devez fournir vos informations d’identification AWS à l’GitHub CLI : région, clé d’accès, clé secrète et jeton de session (si nécessaire). Vous pouvez les passer comme des arguments ou définir des variables d’environnement appelées AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY et AWS_SESSION_TOKEN.

Vous devez également passer le nom du compartiment S3 en utilisant l’argument --aws-bucket-name.

Configuration des informations d’identification du compte Stockage Blob Azure dans GitHub CLI

Lorsque vous êtes prêt à exécuter votre migration, vous pouvez passer votre chaîne de connexion à GitHub CLI en tant qu’argument, ou la passer en utilisant une variable d’environnement appelée AZURE_STORAGE_CONNECTION_STRING.

Étape 5 : Générer un script de migration

Si vous souhaitez migrer simultanément plusieurs dépôts vers GitHub Enterprise Cloud, utilisez GitHub CLI pour générer un script de migration. Le script résultant contiendra une liste de commandes de migration, une par dépôt.

Remarque : La génération d’un script génère un script PowerShell. Si vous utilisez le Terminal, vous devez générer le script avec l’extension de fichier .ps1 et installer PowerShell pour Mac ou Linux pour l’exécuter.

Si vous souhaitez migrer un seul dépôt, passez à l’étape suivante.

Génération d’un script de migration

Vous devez suivre cette étape à partir d’un ordinateur qui peut accéder à l’API pour votre instance GitHub Enterprise Server. Si vous pouvez accéder à votre instance à partir du navigateur, l’ordinateur dispose de l’accès approprié.

Pour générer un script de migration, exécutez la commande gh gei generate-script.

Pour GitHub Enterprise Server 3.8 ou version ultérieure, ou si vous utilisez la version 3.7 ou une version antérieure avec le Stockage Blob Azure, utilisez les indicateurs suivants :

Shell
gh gei generate-script --github-source-org SOURCE \
  --github-target-org DESTINATION \
  --output FILENAME \
  --ghes-api-url GHES-API-URL

Si vous utilisez GitHub Enterprise Server 3.7 ou une version antérieure avec AWS S3, utilisez les indicateurs suivants :

Shell
gh gei generate-script --github-source-org SOURCE \
  --github-target-org DESTINATION \
  --output FILENAME \
  --ghes-api-url GHES-API-URL \
  --aws-bucket-name AWS-BUCKET-NAME

Si votre instance GitHub Enterprise Server utilise un certificat SSL auto-signé ou non valide, utilisez l’indicateur --no-ssl-verify. Avec cet indicateur, GitHub CLI ignore la vérification du certificat SSL lors de l’extraction des données de votre instance uniquement. Tous les autres appels vérifient SSL.

Si vous souhaitez que le script télécharge le journal de migration pour chaque dépôt migré, ajoutez l’indicateur --download-migration-logs. Pour plus d’informations sur les journaux de migration, consultez « Accès à vos journaux de migration pour GitHub Enterprise Importer ».

Remplacez les espaces réservés dans la commande ci-dessus par les valeurs suivantes.

Espace réservéValeur
SOURCENom de l’organisation source
DESTINATIONNom de l’organisation de destination
FILENAMENom de fichier du script de migration résultant

Si vous utilisez le Terminal, choisissez une extension de fichier .ps1, car le script généré exige l’exécution de PowerShell. Vous pouvez installer PowerShell pour Mac ou Linux.
GHES-API-URLURL pour l’API de votre instance GitHub Enterprise Server, par exemple https://myghes.com/api/v3
AWS-BUCKET-NAMENom de compartiment pour votre compartiment AWS S3

Examen du script de migration

Après avoir généré le script, passez en revue le fichier et, éventuellement, modifiez le script.

  • S’il y a des dépôts que vous ne souhaitez pas migrer, supprimez ou commentez les lignes correspondantes.
  • Si vous souhaitez que les dépôts aient un nom différent dans l’organisation de destination, mettez à jour la valeur de l’indicateur --target-repo correspondant.

Remarque : Si votre dépôt contient plus de 10 Go de données de mise en production, les mises en production ne peuvent pas être migrées. Utilisez l’indicateur --skip-releases pour migrer le dépôt sans les mises en production.

Remarque : Si votre dépôt contient plus de 10 Go de données de mise en production, les mises en production ne peuvent pas être migrées. Utilisez l’indicateur --skip-releases pour migrer le dépôt sans les mises en production.

Étape 6 : Migrer des dépôts

Vous pouvez migrer plusieurs dépôts à l’aide d’un script de migration ou un seul dépôt avec la commande gh gei migrate-repo.

Quand vous migrez des dépôts, l’GEI extension of the GitHub CLI effectue les étapes suivantes :

  1. Se connecte à votre instance GitHub Enterprise Server et génère deux archives de migration par dépôt, une pour la source Git et une pour les métadonnées
  2. Charge les archives de migration sur le fournisseur de stockage d’objets blob de votre choix
  3. Démarre votre migration dans GitHub Enterprise Cloud à l’aide des URL des archives stockées avec votre fournisseur de stockage blob
  4. Supprime l’archive de migration de votre ordinateur local

Migrer plusieurs dépôts

Si vous effectuez une migration à partir de GitHub Enterprise Server 3.7 ou version antérieure, avant d’exécuter votre script, vous devez définir des variables d’environnement supplémentaires pour vous authentifier sur votre fournisseur de stockage blob.

  • Pour Stockage Blob Azure, définissez AZURE_STORAGE_CONNECTION_STRING avec la chaîne de connexion de votre compte de stockage Azure.

    Seules les chaînes de connexion utilisant des clés d’accès au compte de stockage sont prises en charge. Les chaînes de connexion qui utilisent des signatures d’accès partagé (SAS) ne sont pas prises en charge. Pour plus d’informations sur les clés d’accès au compte de stockage, consultez Gérer les clés d’accès au compte de stockage dans la documentation Azure.

  • Pour AWS S3, définissez les variables d’environnement suivantes.

Pour migrer plusieurs dépôts, exécutez le script que vous avez généré ci-dessus. Remplacez FILENAME dans les commandes ci-dessous par le nom de fichier que vous avez fourni lors de la génération du script.

  • Si vous employez le Terminal, utilisez ./.

    Shell
    ./FILENAME
    
  • Si vous employez PowerShell, utilisez .\.

    Shell
    .\FILENAME
    

Migrer un seul dépôt

Vous devez suivre cette étape à partir d’un ordinateur qui peut accéder à l’API pour votre instance GitHub Enterprise Server. Si vous pouvez accéder à votre instance à partir du navigateur, l’ordinateur dispose de l’accès approprié.

Pour migrer un seul dépôt, utilisez la commande gh gei migrate-repo.

Si vous utilisez GitHub Enterprise Server 3.8 ou version ultérieure, utilisez les indicateurs suivants :

Shell
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME --ghes-api-url GHES-API-URL

Si vous effectuez une migration à partir de GitHub Enterprise Server 3.7 ou version antérieure et que vous utilisez le Stockage Blob Azure comme fournisseur de stockage blob, utilisez les indicateurs suivants pour vous authentifier :

Shell
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME \
    --ghes-api-url GHES-API-URL --azure-storage-connection-string "AZURE_STORAGE_CONNECTION_STRING"

Si vous effectuez une migration à partir de GitHub Enterprise Server 3.7 ou version antérieure et que vous utilisez Amazon S3 comme fournisseur de stockage blob, utilisez les indicateurs suivants pour vous authentifier :

Shell
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME \
    --ghes-api-url GHES-API-URL --aws-bucket-name "AWS-BUCKET-NAME"

Si votre instance GitHub Enterprise Server utilise un certificat SSL auto-signé ou non valide, utilisez l’indicateur --no-ssl-verify. Avec cet indicateur, GitHub CLI ignore la vérification du certificat SSL lors de l’extraction des données de votre instance uniquement. Tous les autres appels vérifient SSL.

Remarque : Si votre dépôt contient plus de 10 Go de données de mise en production, les mises en production ne peuvent pas être migrées. Utilisez l’indicateur --skip-releases pour migrer le dépôt sans les mises en production.

Remplacez les espaces réservés dans la commande ci-dessus par les valeurs suivantes.

Espace réservéValeur
SOURCENom de l’organisation source
CURRENT-NAMENom du dépôt que vous souhaitez migrer
DESTINATIONNom de l’organisation de destination
NEW-NAMENom que vous souhaitez donner au dépôt migré
GHES-API-URLURL pour l’API de votre instance GitHub Enterprise Server, par exemple https://myghes.com/api/v3
AZURE_STORAGE_CONNECTION_STRINGChaîne de connexion pour votre compte de stockage Azure.

Veillez à mettre entre guillemets la chaîne de connexion, qui contient des caractères qui sinon seraient probablement interprétés par l’interpréteur de commandes.
AWS-BUCKET-NAMENom de compartiment pour votre compartiment AWS S3

Étape 7 : Valider votre migration et consulter le journal des erreurs

Une fois votre migration terminée, nous vous recommandons d’examiner votre journal de migration. Pour plus d’informations, consultez « Accès à vos journaux de migration pour GitHub Enterprise Importer ».

Nous vous recommandons de passer en revue vos dépôts migrés pour en contrôler l’intégrité.

Une fois votre migration terminée, nous vous recommandons de supprimer les archives de votre conteneur de stockage. Si vous prévoyez d’effectuer d’autres migrations, supprimez l’archive placée dans votre conteneur de stockage par l’ADO2GH extension. Si vous avez terminé la migration, vous pouvez supprimer l’intégralité du conteneur.