Prise en charge de la migration pour GitHub Enterprise Importer

Dans cet article

GitHub Enterprise Importer migre diverses données vers GitHub à partir de nos sources prises en charge.

À propos de la prise en charge de la migration pour GitHub Enterprise Importer

GitHub Enterprise Importer peut effectuer une migration vers GitHub Enterprise Cloud à partir de nos sources de migration prises en charge. Les données incluses dans chaque migration dépendent de la source.

GitHub Enterprise Importer prend en charge les migrations vers GitHub Enterprise Cloud à partir des sources suivantes.

  • Cloud Azure DevOps (ADO)
  • Bitbucket Server et Bitbucket Data Center 5.14+
  • GitHub.com
  • GitHub Enterprise Server (GHES) 3.4.1+

Pendant la version bêta, il existe des limitations connues pour Importer qui s’appliquent à toutes les sources.

Prise en charge de la migration Azure DevOps

Si votre source de migration est Azure DevOps, vous pouvez migrer des dépôts.

Vous pouvez uniquement utiliser GitHub Enterprise Importer pour migrer à partir d’Azure DevOps Cloud, et non à partir d’Azure DevOps Server. Si vous utilisez actuellement Azure DevOps Server et souhaitez effectuer une migration vers GitHub, vous pouvez d’abord le faire vers Azure DevOps Cloud. Pour plus d’informations, consultez Migrez vers Azure DevOps sur le site Azure.

Actuellement, nous prenons uniquement en charge la migration des données de dépôt suivantes depuis Azure DevOps vers GitHub Enterprise Cloud.

  • Source Git (y compris l’historique des commits)
  • Demandes de tirage
  • Historique utilisateur pour les demandes de tirage
  • Liens d’élément de travail sur les demandes de tirage
  • Pièces jointes sur les demandes de tirage
  • Protections de branche pour le dépôt (protections de branches délimitées à l’utilisateur non incluses)

Si vous souhaitez migrer Azure Pipelines vers GitHub Actions, contactez votre responsable de compte GitHub.

Prise en charge de la migration de Bitbucket Server

Les migrations à partir de Bitbucket Server sont uniquement prises en charge pour Bitbucket Server ou Bitbucket Data Center version 5.14+ ou ultérieure.

Si votre source de migration est Bitbucket Server, vous pouvez migrer des dépôts. Actuellement, nous prenons uniquement en charge la migration des données de dépôt suivantes depuis Bitbucket Server vers GitHub Enterprise Cloud.

  • Source Git (y compris l’historique des commits)
  • Demandes de tirage (y compris les commentaires, les révisions de demande de tirage, les commentaires révision de demande de tirage au niveau du fichier et de la ligne, les réviseurs requis et les pièces jointes)

Actuellement, les données suivantes ne sont pas migrées.

  • Référentiels personnels détenus par les utilisateurs
  • Autorisations de branche
  • Commentaires de commit
  • Paramètres du référentiel

GitHub Enterprise Importer ne migre pas les pipelines CI à partir de Bitbucket Server.

Prise en charge de la migration GitHub.com

Si votre source de migration est GitHub.com, vous pouvez migrer des dépôts individuels ou des organisations entières.

Lorsque vous migrez une organisation, une nouvelle organisation est créée dans le compte d’entreprise de destination. Ensuite, les données suivantes sont migrées vers la nouvelle organisation.

  • Équipes
  • Dépôts
  • Accès des équipes aux dépôts
  • Privilèges des membres
  • Webhooks au niveau de l’organisation
  • Nom de la branche par défaut pour les nouveaux dépôts créés dans l’organisation

Tous les dépôts sont migrés avec une visibilité privée. Si vous souhaitez définir la visibilité d’un dépôt sur public ou interne, vous pouvez le faire après la migration en utilisant l’interface utilisateur ou l’API.

Les appartenances aux équipes ne sont pas migrées. Après la migration, vous devrez ajouter des membres aux équipes migrées. Pour plus d’informations, consultez « Migration entre produits GitHub avec GitHub Enterprise Importer ».

Remarque : Les références à des équipes, telles que @octo-org/octo-team, ne sont pas mises à jour dans le cadre d’une migration d’organisation. Cela risque d’entraîner des problèmes dans l’organisation de destination, comme par exemple les fichiers CODEOWNERS qui ne fonctionnent pas comme prévu. Pour plus d’informations sur la façon de prévenir et de résoudre ces problèmes, consultez « Résolution des problèmes de votre migration avec GitHub Enterprise Importer ».

Lorsque vous migrez un dépôt, directement ou dans le cadre d’une migration d’organisation, seules les données suivantes sont migrées.

  • Source Git (y compris l’historique des commits)
  • Demandes de tirage
  • Problèmes
  • Étapes majeures
  • Wikis
  • Projets (classiques) au niveau du dépôt
  • Workflows GitHub Actions
  • Commentaires de commit
  • Webhooks actifs
  • Rubriques sur les dépôts
  • Paramètres du référentiel
    • Protections de branches (voir « Protections de branches » pour plus d’informations)
    • Paramètres GitHub Pages
    • Références de lien automatique
    • Paramètres GitHub Advanced Security
    • Paramètres de demande de tirage
      • Supprimer automatiquement les branches principales
      • Autoriser la fusion automatique
      • Autoriser les commits de fusion (le paramètre de message de commit est réinitialisé au message par défaut)
      • Autoriser la fusion Squash (le paramètre de message de commit est réinitialisé au message par défaut)
      • Autoriser la fusion de rebasage
  • Mises en production (jusqu’à 10 Go par dépôt)
  • Historique utilisateur pour les données ci-dessus

Actuellement, les données suivantes ne sont pas migrées.

  • Tous les Projects (nouvelle expérience de projet)
  • Résultats Code scanning
  • Vérifications de l’état de la validation
  • Les alertes Dependabot
  • Les secrets Dependabot
  • Les discussions au niveau du dépôt
  • Modifier l’historique des commentaires de problème et des commentaires de demande de tirage
  • Les relations de duplication entre les dépôts (voir « À propos des duplications (fork) »)
  • Les secrets GitHub Actions, les variables, les environnements, les exécuteurs auto-hébergés, les exécuteur plus grand ou l’historique des exécutions de flux de travail
  • Les secrets GitHub Codespaces
  • Applications GitHub et installations d’applications GitHub
  • Les objets Git LFS et les grands binaires (les dépôts utilisant Git LFS sont toujours pris en charge, voir « Limitations de GitHub Enterprise Importer »)
  • Les packages dans GitHub Packages
  • Les projets (classiques) au niveau de l’organisation
  • Références entre les demandes de tirage et les problèmes dans différents référentiels (consultez « Références et URL automatiquement liées »)
  • Les états de correction des résultats d’secret scanning
  • Référentiels appartenant à des comptes d'utilisateurs
  • Propriétés du référentiel (bêta publique)
  • Étoiles de référentiel
  • Observateurs de référentiels
  • Ensembles de règles
  • Règles de protection des étiquettes
  • Profils utilisateurs, clés SSH, clés KSK ou personal access tokens
  • Secrets de webhook
  • Accès utilisateur au dépôt

Lorsque vous migrez un dépôt directement, les équipes et l’accès des équipes aux dépôts ne sont pas migrés.

Protections de branche

Les protections de branches appliquent un ensemble de règles spécifié à un nom de branche ou à un modèle de nom de branche spécifique. Pour plus d’informations, consultez « À propos des branches protégées ».

Les protections de branches seront toujours migrées, mais certaines règles ne seront pas migrées. Les règles de protection de branche suivantes ne sont pas migrées.

  • Autoriser des acteurs spécifiques à contourner les demandes de tirage requises
  • Exiger l’approbation de la poussée la plus récente
  • Exiger que les déploiements réussissent avant de fusionner
  • Verrouiller une branche
  • Limiter les poussées qui créent des branches correspondantes
  • Autoriser les envois (push) forcés

Les limitations suivantes s'appliquent également :

  • Si une règle de protection de branches vous permet éventuellement de spécifier des personnes, des équipes ou des applications qui sont exemptées de la règle, par exemple « Restreindre qui peut ignorer les révisions de demande de tirage », les exceptions ne sont pas migrées.
  • Si la règle « Autoriser les poussées forcées » est activée en mode « Spécifier qui peut forcer la poussée », la règle n’est pas migrée.

Prise en charge de la migration de GitHub Enterprise Server

Si votre source de migration est GitHub Enterprise Server, vous pouvez migrer des dépôts.

Pour migrer à partir de GitHub Enterprise Server (GHES), vous devez avoir GHES version 3.4.1 ou ultérieure.

ÉlémentGHES 3.4.1+GHES 3.5.0+
Source Git (y compris l’historique des commits)XX
Demandes de tirageXX
ProblèmesXX
Étapes majeuresXX
WikisXX
Projets (classiques) au niveau du dépôtXX
Workflows GitHub ActionsXX
Commentaires de commitXX
Webhooks actifsXX
Protections de brancheXX
Paramètres GitHub PagesXX
Historique utilisateur pour les données ci-dessusXX
Versions
X

Différentes limites de taille par dépôt s’appliquent en fonction de votre version de GHES.

LimiteGHES <3.8.0GHES 3.8.0+
Source Git2 Go10 Go
Métadonnées2 Go10 Go

Actuellement, les données suivantes ne sont pas migrées.

  • Tous les Projects (nouvelle expérience de projet)
  • Résultats Code scanning
  • Vérifications de l’état de la validation
  • Les alertes Dependabot
  • Les secrets Dependabot
  • Les discussions au niveau du dépôt
  • Modifier l’historique des commentaires de problème et des commentaires de demande de tirage
  • Les relations de duplication entre les dépôts (voir « À propos des duplications (fork) »)
  • Les secrets GitHub Actions, les variables, les environnements, les exécuteurs auto-hébergés, les exécuteur plus grand ou l’historique des exécutions de flux de travail
  • Les secrets GitHub Codespaces
  • Applications GitHub et installations d’applications GitHub
  • Les objets Git LFS et les grands binaires (les dépôts utilisant Git LFS sont toujours pris en charge, voir « Limitations de GitHub Enterprise Importer »)
  • Les packages dans GitHub Packages
  • Les projets (classiques) au niveau de l’organisation
  • Références entre les demandes de tirage et les problèmes dans différents référentiels (consultez « Références et URL automatiquement liées »)
  • Les états de correction des résultats d’secret scanning
  • Référentiels appartenant à des comptes d'utilisateurs
  • Propriétés du référentiel (bêta publique)
  • Étoiles de référentiel
  • Observateurs de référentiels
  • Ensembles de règles
  • Règles de protection des étiquettes
  • Profils utilisateurs, clés SSH, clés KSK ou personal access tokens
  • Secrets de webhook
  • Équipes
  • Accès des utilisateurs ou des équipes au dépôt
  • Paramètres de dépôt pour les demandes de tirage

Limites

Il existe des limites à ce que GitHub Enterprise Importer peut migrer. Certaines sont dues à des limitations de GitHub.com, tandis que d’autres sont des limitations de GitHub Enterprise Importer lui-même.

Limitations de GitHub.com

  • Taille limite de 2 Go pour un commit Git : Aucun commit de votre dépôt Git ne peut dépasser 2 Go. Si l’un de vos commits dépasse 2 Go, vous devez le diviser en commits plus petits de 2 Go chacun ou moins.
  • Limite de 255 octets pour les références Git : Aucune référence Git, communément appelée « ref », ne peut avoir un nom qui dépasse 255 octets. En règle générale, cela signifie que vos références ne peuvent pas contenir plus de 255 caractères, mais tous les caractères non-ASCII, tels que les emojis, peuvent consommer plus d’un octet. Si l’une de vos références Git est trop grande, nous retournons un message d’erreur clair.
  • Taille limite de fichier de 100 Mo : Aucun fichier dans votre dépôt Git ne peut dépasser 100 Mo. Envisagez d’utiliser Git LFS pour stocker des gros fichiers. Pour plus d’informations, consultez « Gestion des fichiers volumineux ».

Limitations de GitHub Enterprise Importer

  • Taille limite de 10 Go pour un dépôt Git : Cette limite s’applique uniquement au code source. Pour inspecter la taille de votre dépôt, utilisez l’outil git-sizer et vérifiez la taille totale des blobs.
  • Limite de 10 Go pour les métadonnées : Importer ne peut pas migrer les dépôts qui ont plus de 10 Go de métadonnées. Les métadonnées comprennent les problèmes, les demandes de tirage, les mises en production et les pièces jointes. Dans la plupart des cas, les métadonnées volumineuses sont dues aux ressources binaires attachées aux mises en production. Vous pouvez exclure des mises en production de la migration avec l’indicateur --skip-releases de la commande migrate-repo, puis déplacer vos mises en production manuellement après la migration.
  • Objets Git LFS non migrés : Importer peut migrer les dépôts qui utilisent Git LFS, mais les objets LFS eux-mêmes ne seront pas migrés. Ils peuvent être poussés vers votre destination de migration en tant que tâche de suivi une fois la migration terminée. Pour plus d’informations, consultez « Duplication d’un dépôt ».
  • Tâches de suivi requises : Lors de la migration entre produits GitHub, certains paramètres ne sont pas migrés et doivent être reconfigurés dans le nouveau dépôt. Pour obtenir la liste des tâches de suivi que vous devrez effectuer après chaque migration, consultez « Migration entre produits GitHub avec GitHub Enterprise Importer ».
  • Fonctionnalité de recherche de code différée : La réindexation de l’index de recherche peut prendre quelques heures après la migration d’un dépôt, et les recherches de code peuvent retourner des résultats inattendus tant que la réindexation n’est pas terminée.
  • Les ensembles de règles configurés pour votre organisation peuvent entraîner l’échec des migrations : Par exemple, si vous avez configuré une règle qui exige que les adresses e-mail des auteurs de commit se terminent par @monalisa.cat, et que le dépôt que vous migrez contient des commits qui ne sont pas conformes à cette règle, votre migration échoue. Pour plus d’informations sur les ensembles de règles, consultez « À propos des ensembles de règles ».