Skip to main content

Utiliser GraphQL pour migrer des référentiels d’Azure DevOps vers GitHub Enterprise Cloud

Vous pouvez créer votre propre outil pour migrer des référentiels d’Azure DevOps vers GitHub Enterprise Cloud à l’aide de l’API GraphQL.

Remarque

Vous pouvez également utiliser ADO2GH extension of the GitHub CLI pour effectuer votre migration. Consultez Phase 1. Comprendre les migrations d’Azure DevOps vers GitHub.

Étape 0 : Se préparer pour utiliser l’API GraphQL GitHub

Pour créer des requêtes GraphQL, vous devez écrire vos propres scripts ou utiliser un client HTTP comme Insomnia.

Pour en savoir plus sur l’utilisation de l’API GraphQL GitHub, notamment sur la façon de s’authentifier, consultez Création d’appels avec GraphQL.

Vous enverrez toutes les requêtes GraphQL à la destination de votre migration. Si vous migrez vers GitHub Enterprise Cloud avec résidence des données, veillez à envoyer des requêtes au point de terminaison du sous-domaine de votre entreprise, GHE.com.

Étape 1 : Obtenir le ownerId de la destination de votre migration

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 2 : Identifier à partir d’où vous effectuez la migration

Votre source de migration est votre organisation ADO.

Mutation createMigrationSource

mutation createMigrationSource($name: String!, $ownerId: ID!) {
  createMigrationSource(input: {name: $name, url: "https://dev.azure.com", ownerId: $ownerId, type: AZURE_DEVOPS}) {
    migrationSource {
      id
      name
      url
      type
    }
  }
}

Remarque

Veillez à utiliser AZURE_DEVOPS 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.

Réponse createMigrationSource

{
  "data": {
    "createMigrationSource": {
      "migrationSource": {
        "id": "MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA",
        "name": "Azure DevOps Source",
        "url": "https://dev.azure.com",
        "type": "AZURE_DEVOPS"
      }
    }
  }
}

Dans cet exemple, MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA est l’ID de la source de la migration, que nous allons utiliser à l’étape suivante.

Étape 3 : 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!,
  $sourceRepositoryUrl: URI!,
  $repositoryName: String!,
  $continueOnError: Boolean!,
  $accessToken: String!,
  $githubPat: String!,
  $targetRepoVisibility: String!
){
  startRepositoryMigration( input: {
    sourceId: $sourceId,
    ownerId: $ownerId,
    repositoryName: $repositoryName,
    continueOnError: $continueOnError,
    accessToken: $accessToken,
    githubPat: $githubPat,
    targetRepoVisibility: $targetRepoVisibility,
    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.
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.
sourceRepositoryUrlURL de votre dépôt source, au format https://dev.azure.com/{organization}/{project}/_git/{repository}.

Pour connaître les exigences relatives aux personal access token, veuillez consulter la section Phase 2. Gérer l’accès.

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

Étape 4 : 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 5 : Valider votre migration et consulter le journal des erreurs

Lectures complémentaires

  •         [AUTOTITLE](/migrations/ado/phase-6-follow-up-tasks)
    
  •         [AUTOTITLE](/migrations/ado/key-differences-between-azure-devops-and-github)