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

À 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 :

Créer un personal access token pour les organisations source et de destination
Récupérer le ownerId de l’organisation de destination sur GitHub Enterprise Cloud
Configurer une source de migration via l’API GraphQL de GitHub pour identifier l’emplacement d’origine de la migration
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
- Démarrer votre migration à l’aide de l’API GraphQL pour GitHub, 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

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 exécutions d’essai, consultez « Vue d’ensemble d’une migration entre produits GitHub ».
Assurez-vous que vous comprenez les données qui seront migrées et les limitations de prise en charge connues de l’importateur. Pour plus d’informations, consultez « Informations sur les migrations entre les produits GitHub ».
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 « Gestion de l'accès pour une migration entre les produits GitHub ».
Si vous utilisez GitHub Enterprise Server 3.8 ou ultérieur, pour configurer le stockage blob pour les archives exportées, vous devez avoir accès à la Management Console.

Étape 1. Créer votre personal access token

Créez et enregistrez un personal access token (classic) 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 une migration entre les produits GitHub ».
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ête	Description
`login`	Nom 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 ».

À partir d’un compte d’administration sur GitHub Enterprise Server, cliquez sur en haut à droite de n’importe quelle page.
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 .
Connectez-vous à la Management Console.
Dans la barre de navigation supérieure, cliquez sur Paramètres.
Sous Migrations, cliquez sur Activer les migrations GitHub .
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 ».

Remarque : après avoir copié vos paramètres de stockage, vous devrez peut-être toujours mettre à jour la configuration de votre compte de stockage cloud pour utiliser GitHub Enterprise Importer. Vous devez notamment vous assurer que les adresses IP de GitHub figurent dans la liste d'autorisation. Pour plus d’informations, consultez « Gestion de l'accès pour une migration entre les produits GitHub ».
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.
Cliquez sur Tester les paramètres de stockage.
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ête	Description
`name`	Nom pour votre source de migration. Ce nom est juste pour vous, donc vous pouvez utiliser n’importe quelle chaîne.
`ownerId`	ID d’organisation de votre organisation sur GitHub Enterprise Cloud.
`url`	URL 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 .»

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 ».

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 .»

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, à 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. 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 une migration entre les produits GitHub ».

É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ête	Description
`sourceId`	`id` de votre source de migration retournée par la mutation `createMigrationSource`.
`ownerId`	ID d’organisation de votre organisation sur GitHub Enterprise Cloud.
`repositoryName`	Nom 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.
`continueOnError`	Paramè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.
`githubPat`	personal access token pour votre organisation de destination sur GitHub Enterprise Cloud.
`accessToken`	personal access token pour votre source.
`targetRepoVisibility`	Visibilité 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.
`gitArchiveUrl`	URL de l’archive de votre source Git accessible à GitHub Enterprise Cloud.
`metadataArchiveUrl`	URL de l’archive de vos métadonnées accessible à GitHub Enterprise Cloud.
`sourceRepositoryUrl`	URL 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.

Pour connaître les exigences en termes de personal access token, consultez « Gestion de l'accès pour une migration entre les produits GitHub ».

À 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ête	Description
`id`	`id` 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 ».

Vous pouvez également télécharger un fichier binaire autonome à partir de la page des versions du référentiel github/gh-gei. Vous pouvez exécuter le fichier binaire directement, sans le préfixe gh.

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.

Installez GEI extension.

Shell

gh extension install github/gh-gei

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.

Créez et enregistrez un personal access token (classic) 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 une migration entre les produits GitHub ».
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.
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"
```
```
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"
```
```
$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/*"
            ]
        }
    ]
}

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.

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.

À partir d’un compte d’administration sur GitHub Enterprise Server, cliquez sur en haut à droite de n’importe quelle page.
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 .
Connectez-vous à la Management Console.
Dans la barre de navigation supérieure, cliquez sur Paramètres.
Sous Migrations, cliquez sur Activer les migrations GitHub .
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 ».

Remarque : après avoir copié vos paramètres de stockage, vous devrez peut-être toujours mettre à jour la configuration de votre compte de stockage cloud pour utiliser GitHub Enterprise Importer. Vous devez notamment vous assurer que les adresses IP de GitHub figurent dans la liste d'autorisation. Pour plus d’informations, consultez « Gestion de l'accès pour une migration entre les produits GitHub ».
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.
Cliquez sur Tester les paramètres de stockage.
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

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

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
SOURCE	Nom de l’organisation source
DESTINATION	Nom de l’organisation de destination
FILENAME	Nom 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-URL	URL pour l’API de votre instance GitHub Enterprise Server, par exemple `https://myghes.com/api/v3`
AWS-BUCKET-NAME	Nom 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.
Si vous souhaitez modifier la visibilité du nouveau référentiel, mettez à jour la valeur de l’indicateur --target-repo-visibility correspondant. Par défaut, le script définit la même visibilité que le référentiel source.

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.

Si vous avez téléchargé GEI en tant que fichier binaire autonome plutôt qu’en tant qu’extension pour GitHub CLI, vous devrez mettre à jour votre script généré pour exécuter le fichier binaire au lieu de gh gei.

É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 :

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
Charge les archives de migration sur le fournisseur de stockage d’objets blob de votre choix
Démarre votre migration dans GitHub Enterprise Cloud à l’aide des URL des archives stockées avec votre fournisseur de stockage blob
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.
- AWS_ACCESS_KEY_ID : ID de clé d’accès de votre compartiment
- AWS_SECRET_ACCESS_KEY : clé secrète de votre compartiment
- AWS_REGION : région AWS où se trouve votre compartiment
- AWS_SESSION_TOKEN : jeton de session, si vous utilisez des informations d’identification AWS temporaires (consultez Utilisation d’informations d’identification temporaires avec des ressources AWS dans la documentation AWS)

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
```
```
./FILENAME
```
Si vous employez PowerShell, utilisez .\.
Shell
```
.\FILENAME
```
```
.\FILENAME
```

Migrer un seul dépôt

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

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"

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"

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"

Les dépôts sont migrés avec une visibilité privée par défaut. Pour définir la visibilité, vous pouvez ajouter l’indicateur --target-repo-visibility, spécifier private, public, ou internal. Si vous effectuez une migration vers un entreprise avec utilisateurs managés, les référentiels publics ne sont pas disponibles.

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

Espace réservé	Valeur
SOURCE	Nom de l’organisation source
CURRENT-NAME	Nom du dépôt que vous souhaitez migrer
DESTINATION	Nom de l’organisation de destination
NEW-NAME	Nom que vous souhaitez donner au dépôt migré
GHES-API-URL	URL pour l’API de votre instance GitHub Enterprise Server, par exemple `https://myghes.com/api/v3`
AZURE_STORAGE_CONNECTION_STRING	Chaî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-NAME	Nom de compartiment pour votre compartiment AWS S3

Si vous souhaitez annuler une migration, utilisez la commande abort-migration, en remplaçant MIGRATION-ID par l'ID retourné par migrate-repo.

Shell

gh gei abort-migration --migration-id MIGRATION-ID

gh gei abort-migration --migration-id MIGRATION-ID

É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.

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

Tool navigation

Dans cet article