Passer au contenu principal

Production (GitLab)

Migration depuis GitHub et Gitea

La migration vers GitLab depuis d'autres forges couvre le code source, les issues, les MR/PR, les membres et les integrations CI/CD. L'outil de migration integre de GitLab supporte GitHub en premiere classe ; Gitea et les autres forges necessitent des approches complementaires.

Migration depuis GitHub

GitLab fournit un importeur GitHub natif (GitLab UI > New Project > Import project > GitHub). Il importe :

  • Le depot Git (tous les commits et branches)
  • Les issues et leurs commentaires
  • Les Pull Requests converties en Merge Requests
  • Les labels, milestones et releases
  • Les wikis
  • Les membres (si le compte GitLab correspond a l'identifiant GitHub)

L'import necessite un token GitHub avec scope repo. Le temps d'import depend de la taille du depot et du nombre d'issues. Les GitHub Actions ne sont pas converties : la CI/CD doit etre reecrite en .gitlab-ci.yml.

Migration en masse via API

Pour migrer une organisation entiere, GitLab propose la migration par groupe via l'interface (Admin > Migrations > GitHub) ou via l'API. L'outil CLI gl-exporter (maintenu par la communaute) permet d'exporter et d'importer en lot.

Migration depuis Gitea

GitLab n'a pas d'importeur natif pour Gitea. L'approche manuelle :

  • Migrer le code Git avec un simple git clone --mirror + push vers GitLab
  • Exporter les issues Gitea via l'API Gitea (JSON) et les reimporter via l'API GitLab
  • Recreer les webhooks et les integrations manuellement

Des outils communautaires comme gitea-github-migrator ou des scripts Python maison sont souvent plus rapides qu'une migration manuelle pour plus de quelques dizaines de projets.

Réécriture de la CI/CD

C'est le chantier le plus important. GitHub Actions et GitLab CI/CD partagent des concepts (jobs, steps, triggers) mais la syntaxe est differente. Les equivalences principales :

  • on: push -> rules: - if: $CI_PIPELINE_SOURCE == "push"
  • jobs.steps -> script:
  • uses: actions/checkout@v4 -> clone automatique dans GitLab CI
  • secrets.TOKEN -> variables CI/CD protegees
  • GitHub Actions marketplace -> templates GitLab CI ou images Docker equivalentes

Plan de migration recommande

  • Phase 1 : migrer le code et les issues, mode miroir actif
  • Phase 2 : reecrire la CI/CD, tester en parallele
  • Phase 3 : basculer les acces et les webhooks
  • Phase 4 : coupure du service GitHub, redirection DNS/liens si necessaire

Sources