Skip to main content

Enterprise Server 3.15 est actuellement disponible en tant que version finale (RC).

Migration depuis GitLab avec GitHub Actions Importer

DĂ©couvrez comment utiliser GitHub Actions Importer pour automatiser la migration de vos pipelines GitLab vers GitHub Actions.

Mentions légales

À propos de la migration depuis GitLab avec GitHub Actions Importer

Les instructions ci-dessous vous guident tout au long de la configuration de votre environnement pour utiliser GitHub Actions Importer afin de migrer des pipelines GitLab vers GitHub Actions.

Prérequis

  • Un compte GitLab ou une organisation avec des pipelines et des travaux que vous souhaitez convertir en workflows GitHub Actions.

  • AccĂšs pour crĂ©er un personal access token GitLab pour votre compte ou organisation.

  • Un environnement dans lequel vous pouvez exĂ©cuter des conteneurs basĂ©s sur Linux et installer les outils nĂ©cessaires.

    Remarque : Le conteneur GitHub Actions Importer et l’interface CLI n’ont pas besoin d’ĂȘtre installĂ©s sur le mĂȘme serveur que votre plateforme CI.

Limites

Certaines limitations s’appliquent à la migration automatique des processus des pipelines GitLab vers GitHub Actions avec GitHub Actions Importer.

  • La mise en cache automatique entre les travaux de diffĂ©rents workflows n’est pas prise en charge.
  • La commande audit est uniquement prise en charge lors de l’utilisation d’un compte d’organisation. Toutefois, les commandes dry-run et migrate peuvent ĂȘtre utilisĂ©es avec une organisation ou un compte d’utilisateur.

TĂąches manuelles

Certaines constructions GitLab doivent ĂȘtre migrĂ©es manuellement. Il s’agit notamment des paramĂštres suivants :

  • Valeurs de variables de groupe ou de projet masquĂ©es
  • Rapports d’artefact

Pour plus d’informations sur les migrations manuelles, consultez « Migration de GitLab CI/CD vers GitHub Actions ».

Installation de l’extension CLI GitHub Actions Importer

  1. Installez l’extension CLI GitHub Actions Importer :

    Bash
    gh extension install github/gh-actions-importer
    
  2. VĂ©rifiez que l’extension est installĂ©e :

    $ gh actions-importer -h
    Options:
      -?, -h, --help  Show help and usage information
    
    Commands:
      update     Update to the latest version of GitHub Actions Importer.
      version    Display the version of GitHub Actions Importer.
      configure  Start an interactive prompt to configure credentials used to authenticate with your CI server(s).
      audit      Plan your CI/CD migration by analyzing your current CI/CD footprint.
      forecast   Forecast GitHub Actions usage from historical pipeline utilization.
      dry-run    Convert a pipeline to a GitHub Actions workflow and output its yaml file.
      migrate    Convert a pipeline to a GitHub Actions workflow and open a pull request with the changes.
    

Configuration des informations d’identification

La commande CLI configure est utilisĂ©e pour dĂ©finir les informations d’identification et les options requises pour GitHub Actions Importer lors de l’utilisation de GitLab et de GitHub.

  1. CrĂ©ez un personal access token (classic) GitHub. Pour plus d’informations, consultez « Gestion de vos jetons d'accĂšs personnels ».

    Votre jeton doit avoir l’étendue workflow.

    AprĂšs avoir crĂ©Ă© le jeton, copiez-le et enregistrez-le en lieu sĂ»r en vue de l’utiliser ultĂ©rieurement.

  2. CrĂ©er un personal access token GitLab. Pour plus d’informations, consultez Personal access tokens dans la documentation GitLab.

    Votre jeton doit avoir l’étendue read_api.

    AprĂšs avoir crĂ©Ă© le jeton, copiez-le et enregistrez-le en lieu sĂ»r en vue de l’utiliser ultĂ©rieurement.

  3. Dans votre terminal, exécutez la commande CLI GitHub Actions Importer configure :

    gh actions-importer configure
    

    La commande configure vous invite à entrer les informations suivantes :

    • Pour « Quels fournisseurs CI configurez-vous ? », utilisez les touches de direction pour sĂ©lectionner GitLab, appuyez sur Espace pour le sĂ©lectionner, puis appuyez sur EntrĂ©e.
    • Pour « Personal access token pour GitHub », entrez la valeur du personal access token (classic) que vous avez crĂ©Ă©, puis appuyez sur EntrĂ©e.
    • Pour « URL de base de l’instance GitHub », entrez l’URL de votre instance GitHub Enterprise Server, puis appuyez sur EntrĂ©e.
    • Pour « Jeton privĂ© pour GitLab », entrez la valeur du personal access token GitLab que vous avez crĂ©Ă© prĂ©cĂ©demment, puis appuyez sur EntrĂ©e.
    • Pour « URL de base de l’instance GitLab », entrez l’URL de votre instance GitLab, puis appuyez sur EntrĂ©e.

    Voici un exemple de sortie de la commande configure.

    $ gh actions-importer configure
    ✔ Which CI providers are you configuring?: GitLab
    Enter the following values (leave empty to omit):
    ✔ Personal access token for GitHub: ***************
    ✔ Base url of the GitHub instance: https://github.com
    ✔ Private token for GitLab: ***************
    ✔ Base url of the GitLab instance: http://localhost
    Environment variables successfully updated.
    
  4. Dans votre terminal, exĂ©cutez la commande CLI GitHub Actions Importer update pour vous connecter au Container registry GitHub Packages et vĂ©rifier que l’image conteneur est mise Ă  jour vers la derniĂšre version :

    gh actions-importer update
    

    La sortie de la commande devrait ressembler à la sortie ci-dessous :

    Updating ghcr.io/actions-importer/cli:latest...
    ghcr.io/actions-importer/cli:latest up-to-date
    

Effectuer un audit de GitLab

Vous pouvez utiliser la commande audit pour obtenir une vue d’ensemble de tous les pipelines d’un serveur GitLab.

La commande audit effectue les étapes suivantes :

  1. Extrait tous les projets définis dans un serveur GitLab.
  2. Convertit chaque pipeline en son workflow GitHub Actions Ă©quivalent.
  3. GĂ©nĂšre un rapport qui rĂ©sume la complexitĂ© et l’exhaustivitĂ© d’une migration avec GitHub Actions Importer.

PrĂ©requis pour la commande d’audit

Pour utiliser la commande audit, vous devez disposer d’un personal access token configurĂ© avec un compte d’organisation GitLab.

Exécution de la commande audit

Pour effectuer un audit d’un serveur GitLab, exĂ©cutez la commande suivante dans votre terminal, en remplaçant my-gitlab-namespace par l’espace de noms ou le groupe que vous auditez :

gh actions-importer audit gitlab --output-dir tmp/audit --namespace my-gitlab-namespace

Inspection des rĂ©sultats de l’audit

Les fichiers dans le rĂ©pertoire de sortie spĂ©cifiĂ© contiennent les rĂ©sultats de l’audit. Consultez le fichier audit_summary.md pour obtenir un rĂ©sumĂ© des rĂ©sultats de l’audit.

Le rĂ©sumĂ© de l’audit comporte les sections suivantes.

Pipelines

La section « Pipelines » contient des statistiques générales concernant le taux de conversion effectué par GitHub Actions Importer.

Vous trouverez ci-dessous quelques termes clés qui peuvent apparaßtre dans la section « Pipelines » :

  • Les pipelines rĂ©ussis sont ceux dont 100 % des constructions de pipeline et des Ă©lĂ©ments individuels ont Ă©tĂ© convertis automatiquement en leur Ă©quivalent GitHub Actions.
  • Les pipelines partiellement rĂ©ussis sont ceux dont la totalitĂ© des constructions de pipeline ont Ă©tĂ© converties ; toutefois, certains Ă©lĂ©ments individuels n’ont pas Ă©tĂ© convertis automatiquement en leur Ă©quivalent GitHub Actions.
  • Les pipelines non pris en charge sont des types de dĂ©finition qui ne sont pas pris en charge par GitHub Actions Importer.
  • Les pipelines ayant Ă©chouĂ© sont ceux qui ont rencontrĂ© une erreur irrĂ©cupĂ©rable lors de la conversion. Cela peut se produire pour l’une des trois raisons suivantes :
    • Le pipeline a Ă©tĂ© mal configurĂ© Ă  l’origine et n’était pas valide.
    • GitHub Actions Importer a rencontrĂ© une erreur interne lors de sa conversion.
    • Une rĂ©ponse rĂ©seau infructueuse a rendu le pipeline inaccessible, ce qui est souvent dĂ» Ă  des informations d’identification non valides.

Étapes de gĂ©nĂ©ration

La section « Étapes de gĂ©nĂ©ration » contient une vue d’ensemble des Ă©tapes de gĂ©nĂ©ration individuelles utilisĂ©es dans tous les pipelines ainsi que le nombre d’étapes converties automatiquement par GitHub Actions Importer.

Vous trouverez ci-dessous quelques termes clĂ©s qui peuvent apparaĂźtre dans la section « Étapes de gĂ©nĂ©ration » :

  • Une Ă©tape de gĂ©nĂ©ration connue est une Ă©tape qui a Ă©tĂ© automatiquement convertie en action Ă©quivalente.
  • Une Ă©tape de gĂ©nĂ©ration inconnue est une Ă©tape qui n’a pas Ă©tĂ© automatiquement convertie en action Ă©quivalente.
  • Une Ă©tape de gĂ©nĂ©ration non prise en charge est une Ă©tape qui est :
    • Fondamentalement non prise en charge par GitHub Actions.
    • ConfigurĂ© d’une maniĂšre incompatible avec GitHub Actions.
  • Une action est une liste des actions qui ont Ă©tĂ© utilisĂ©es dans les workflows convertis. Cela peut ĂȘtre important pour :
    • Rassembler la liste des actions Ă  synchroniser avec votre instance, si vous utilisez GitHub Enterprise Server.
    • DĂ©finir une liste d’autorisation au niveau de l’organisation des actions utilisĂ©es. Cette liste d’actions est une liste complĂšte d’actions que vos Ă©quipes de sĂ©curitĂ© ou de conformitĂ© peuvent avoir besoin d’examiner.

TĂąches manuelles

La section « TĂąches manuelles » contient une vue d’ensemble des tĂąches que GitHub Actions Importer ne peut pas accomplir automatiquement et que vous devez effectuer manuellement.

Vous trouverez ci-dessous quelques termes clés qui peuvent apparaßtre dans la section « Tùches manuelles » :

  • Un secret est un secret au niveau de l’organisation ou du dĂ©pĂŽt qui est utilisĂ© dans les pipelines convertis. Ces secrets doivent ĂȘtre crĂ©Ă©s manuellement dans GitHub Actions pour que ces pipelines fonctionnent correctement. Pour plus d’informations, consultez « Utilisation de secrets dans GitHub Actions ».
  • Un exĂ©cuteur auto-hĂ©bergĂ© fait rĂ©fĂ©rence Ă  une Ă©tiquette d’un exĂ©cuteur rĂ©fĂ©rencĂ© dans un pipeline converti qui n’est pas un exĂ©cuteur hĂ©bergĂ© par GitHub. Vous devez dĂ©finir manuellement ces exĂ©cuteurs pour que ces pipelines fonctionnent correctement.

Fichiers

La derniĂšre section du rapport d’audit fournit un manifeste de tous les fichiers qui ont Ă©tĂ© Ă©crits sur le disque pendant l’audit.

À chaque fichier de pipeline correspond une sĂ©rie de fichiers inclus dans l’audit, notamment :

  • Le pipeline d’origine tel qu’il a Ă©tĂ© dĂ©fini dans GitHub.
  • Toutes les rĂ©ponses rĂ©seau utilisĂ©es pour convertir le pipeline.
  • Le fichier de workflow converti.
  • Les traces de pile qui peuvent ĂȘtre utilisĂ©es pour rĂ©soudre les problĂšmes liĂ©s Ă  une conversion de pipeline ayant Ă©chouĂ©.

De plus, le fichier workflow_usage.csv contient une liste sĂ©parĂ©e par des virgules de l’ensemble des actions, secrets et exĂ©cuteurs qui sont utilisĂ©s par chaque pipeline converti avec succĂšs. Cela peut ĂȘtre utile pour dĂ©terminer quels workflows utilisent quelles actions, quels secrets ou quels exĂ©cuteurs, et pour effectuer des rĂ©visions de sĂ©curitĂ©.

PrĂ©voir l’utilisation potentielle de l’exĂ©cuteur de gĂ©nĂ©ration

Vous pouvez utiliser la commande forecast pour prĂ©voir l’utilisation potentielle de GitHub Actions en calculant des mĂ©triques Ă  partir des exĂ©cutions de pipeline terminĂ©es sur votre serveur GitLab.

Exécution de la commande forecast

Pour effectuer une prĂ©vision de l’utilisation potentielle de GitHub Actions, exĂ©cutez la commande suivante dans votre terminal, en remplaçant my-gitlab-namespace par l’espace de noms ou le groupe que vous prĂ©disez. Par dĂ©faut, GitHub Actions Importer inclut les sept jours prĂ©cĂ©dents dans le rapport de prĂ©vision.

gh actions-importer forecast gitlab --output-dir tmp/forecast --namespace my-gitlab-namespace

PrĂ©vision d’un espace de noms entier

Pour prĂ©dire un espace de noms entier et tous ses sous-groupes, vous devez spĂ©cifier chaque sous-groupe dans l’argument --namespace ou la variable d’environnement NAMESPACE.

Par exemple :

gh actions-importer forecast gitlab --namespace my-gitlab-namespace my-gitlab-namespace/subgroup-one my-gitlab-namespace/subgroup-two ...

Inspection du rapport de prévision

Le fichier forecast_report.md dans le répertoire de sortie spécifié contient les résultats de la prévision.

Voici quelques termes clés qui peuvent apparaßtre dans le rapport de prévision :

  • Le nombre de travaux correspond au nombre total de travaux terminĂ©s.
  • Le nombre de pipelines correspond au nombre de pipelines uniques utilisĂ©s.
  • Le temps d’exĂ©cution dĂ©crit le temps passĂ© par un exĂ©cuteur sur un travail. Cette mĂ©trique peut ĂȘtre utilisĂ©e pour planifier le coĂ»t des exĂ©cuteurs hĂ©bergĂ©s par GitHub.
    • Cette mĂ©trique est corrĂ©lĂ©e au montant que vous devez vous attendre Ă  dĂ©penser dans GitHub Actions. Cela varie en fonction du matĂ©riel utilisĂ© pendant ces minutes. Vous pouvez utiliser la calculatrice de prix GitHub Actions pour estimer les coĂ»ts.
  • Les mĂ©triques de temps de file d’attente dĂ©crivent le temps passĂ© par un travail Ă  attendre qu’un exĂ©cuteur soit disponible pour l’exĂ©cuter.
  • Les mĂ©triques de travaux simultanĂ©s dĂ©crivent le nombre de travaux en cours d’exĂ©cution Ă  un moment donnĂ©. Cette mĂ©trique peut ĂȘtre utilisĂ©e pour dĂ©finir le nombre d’exĂ©cuteurs que vous devez configurer.

En outre, ces mĂ©triques sont dĂ©finies pour chaque file d’attente d’exĂ©cuteurs dans GitLab. C’est particuliĂšrement utile s’il existe une combinaison d’exĂ©cuteurs hĂ©bergĂ©s ou auto-hĂ©bergĂ©s ou de machines Ă  spĂ©cifications Ă©levĂ©es ou faibles, afin que vous puissiez voir des mĂ©triques spĂ©cifiques Ă  diffĂ©rents types d’exĂ©cuteurs.

Effectuer une migration test d’un pipeline GitLab

Vous pouvez utiliser la commande dry-run pour convertir un pipeline GitLab en son workflow GitHub Actions Ă©quivalent.

Exécution de la commande dry-run

Vous pouvez utiliser la commande dry-run pour convertir un pipeline GitLab en workflow GitHub Actions Ă©quivalent. Une exĂ©cution test crĂ©e les fichiers de sortie dans un rĂ©pertoire spĂ©cifiĂ©, mais n’ouvre pas de demande de tirage pour migrer le pipeline.

Pour effectuer une exĂ©cution de test de migration de vos pipelines GitLab vers GitHub Actions, exĂ©cutez la commande suivante dans votre terminal, en remplaçant my-gitlab-project par le slug de votre projet GitLab et my-gitlab-namespace par l’espace de noms ou le groupe (le chemin d’accĂšs complet au groupe pour les sous-groupes, par ex. my-org/my-team) pour lequel vous effectuez une exĂ©cution de test.

gh actions-importer dry-run gitlab --output-dir tmp/dry-run --namespace my-gitlab-namespace --project my-gitlab-project

Inspection des workflows convertis

Vous pouvez afficher les journaux de l’exĂ©cution test et les fichiers de workflow convertis dans le rĂ©pertoire de sortie spĂ©cifiĂ©.

Pour tout ce que GitHub Actions Importer n’a pas pu convertir automatiquement, comme des Ă©tapes de gĂ©nĂ©ration inconnues ou un pipeline partiellement rĂ©ussi, vous pouvez crĂ©er des transformateurs personnalisĂ©s pour personnaliser davantage le processus de conversion. Pour plus d’informations, consultez « Extension GitHub Actions Importer avec des transformateurs personnalisĂ©s ».

Effectuer une migration de production d’un pipeline GitLab

Vous pouvez utiliser la commande migrate pour convertir un pipeline GitLab et ouvrir une demande de tirage avec le workflow GitHub Actions Ă©quivalent.

Exécution de la commande migrate

Pour migrer un pipeline GitLab vers GitHub Actions, exécutez la commande suivante dans votre terminal, en remplaçant les valeurs suivantes :

  • La valeur target-url avec l’URL de votre dĂ©pĂŽt GitHub Enterprise Server
  • my-gitlab-project avec le slug de votre projet GitLab
  • my-gitlab-namespace avec l’espace de noms ou le groupe vers lequel vous migrez (chemin complet pour les sous-groupes, par ex. my-org/my-team)
gh actions-importer migrate gitlab --target-url https://github.com/:owner/:repo --output-dir tmp/migrate --namespace my-gitlab-namespace --project my-gitlab-project

La sortie de la commande inclut l’URL de la demande de tirage qui ajoute le workflow converti Ă  votre dĂ©pĂŽt. Voici un exemple de sortie rĂ©ussie :

$ gh actions-importer migrate gitlab --target-url https://github.com/octo-org/octo-repo --output-dir tmp/migrate --namespace octo-org --project monas-project
[2022-08-20 22:08:20] Logs: 'tmp/migrate/log/actions-importer-20220916-014033.log'
[2022-08-20 22:08:20] Pull request: 'https://github.com/octo-org/octo-repo/pull/1'

Inspection de la demande de tirage

La sortie d’une exĂ©cution rĂ©ussie de la commande migrate contient un lien vers la nouvelle demande de tirage qui ajoute le workflow converti Ă  votre dĂ©pĂŽt.

Voici quelques éléments importants de la demande de tirage :

  • Dans la description de la demande de tirage, une section appelĂ©e Étapes manuelles, qui liste les Ă©tapes que vous devez effectuer manuellement avant de pouvoir terminer la migration de vos pipelines vers GitHub Actions. Par exemple, cette section peut vous indiquer de crĂ©er des secrets utilisĂ©s dans vos workflows.
  • Fichier de workflows converti. SĂ©lectionnez l’onglet Fichiers changĂ©s dans la demande de tirage pour afficher le fichier de workflow Ă  ajouter Ă  votre dĂ©pĂŽt GitHub Enterprise Server.

Une fois que vous avez terminĂ© d’inspecter la demande de tirage, vous pouvez la fusionner pour ajouter le workflow Ă  votre dĂ©pĂŽt GitHub Enterprise Server.

Informations de référence

Cette section contient des informations de rĂ©fĂ©rence sur les variables d’environnement, les arguments facultatifs et la syntaxe prise en charge lors de l’utilisation de GitHub Actions Importer pour effectuer une migration Ă  partir de GitLab.

Utilisation de variables d’environnement

GitHub Actions Importer utilise des variables d’environnement pour sa configuration d’authentification. Ces variables sont dĂ©finies lors du processus de configuration au moyen de la commande configure. Pour plus d’informations, consultez la section « Configuration des informations d’identification ».

GitHub Actions Importer utilise les variables d’environnement suivantes pour se connecter à votre instance GitLab :

  • GITHUB_ACCESS_TOKEN : personal access token (classic) utilisĂ© pour crĂ©er des demandes de tirage avec un workflow converti (nĂ©cessite l’étendue workflow).
  • GITHUB_INSTANCE_URL : URL de l’instance GitHub cible (par exemple, https://github.com).
  • GITLAB_ACCESS_TOKEN : Le personal access token GitLab utilisĂ© pour afficher les ressources GitLab.
  • GITLAB_INSTANCE_URL : URL de l’instance GitLab.
  • NAMESPACE : espaces de noms ou groupes qui contiennent les pipelines GitLab.

Ces variables d’environnement peuvent ĂȘtre spĂ©cifiĂ©es dans un fichier .env.local chargĂ© par GitHub Actions Importer lors de son exĂ©cution.

Utilisation des arguments facultatifs

Vous pouvez utiliser des arguments facultatifs avec les sous-commandes GitHub Actions Importer pour personnaliser votre migration.

--source-file-path

Vous pouvez utiliser l’argument --source-file-path avec les sous-commandes forecast, dry-run ou migrate.

Par dĂ©faut, GitHub Actions Importer rĂ©cupĂšre le contenu du pipeline Ă  partir du contrĂŽle de code source. L’argument --source-file-path indique Ă  GitHub Actions Importer d’utiliser le chemin du fichier source spĂ©cifiĂ© Ă  la place.

Par exemple :

gh actions-importer dry-run gitlab --output-dir output/ --namespace my-gitlab-namespace --project my-gitlab-project --source-file-path path/to/.gitlab-ci.yml

Si vous souhaitez fournir plusieurs fichiers sources lors de l’exĂ©cution de la sous-commande forecast, vous pouvez utiliser la correspondance de modĂšle dans la valeur du chemin de fichier. L’exemple suivant fournit Ă  GitHub Actions Importer tous les fichiers sources qui correspondent au chemin de fichier ./tmp/previous_forecast/jobs/*.json.

gh actions-importer forecast gitlab --output-dir output/ --namespace my-gitlab-namespace --project my-gitlab-project --source-file-path ./tmp/previous_forecast/jobs/*.json

--config-file-path

Vous pouvez utiliser l’argument --config-file-path avec les sous-commandes audit, dry-run et migrate.

Par dĂ©faut, GitHub Actions Importer rĂ©cupĂšre le contenu du pipeline Ă  partir du contrĂŽle de code source. L’argument --config-file-path indique Ă  GitHub Actions Importer d’utiliser les fichiers sources spĂ©cifiĂ©s Ă  la place.

L’argument --config-file-path peut Ă©galement ĂȘtre utilisĂ© pour spĂ©cifier le rĂ©fĂ©rentiel vers lequel un workflow rĂ©utilisable converti doit ĂȘtre migrĂ©.

Exemple Audit

Dans cet exemple, GitHub Actions Importer utilise le fichier de configuration YAML spécifié pour effectuer un audit.

gh actions-importer audit gitlab --output-dir path/to/output/ --namespace my-gitlab-namespace --config-file-path path/to/gitlab/config.yml

Pour auditer une instance GitLab avec un fichier de configuration, celui-ci doit ĂȘtre au format suivant et chaque valeur repository_slug doit ĂȘtre unique :

source_files:
  - repository_slug: namespace/project-name
    path: path/to/.gitlab-ci.yml
  - repository_slug: namespace/some-other-project-name
    path: path/to/.gitlab-ci.yml
Exemple d’exĂ©cution test

Dans cet exemple, GitHub Actions Importer utilise le fichier de configuration YAML spécifié comme fichier source pour effectuer une exécution test.

Le pipeline est sélectionné en faisant correspondre le repository_slug dans le fichier de configuration à la valeur des options --namespace et --project. path est ensuite utilisé pour tirer (pull) le fichier source spécifié.

gh actions-importer dry-run gitlab --namespace my-gitlab-namespace --project my-gitlab-project-name --output-dir ./output/ --config-file-path ./path/to/gitlab/config.yml
Spécifier le référentiel des workflows réutilisables convertis

GitHub Actions Importer utilise le fichier YAML fourni Ă  l’argument --config-file-path pour dĂ©terminer le rĂ©fĂ©rentiel vers lequel les workflows rĂ©utilisables convertis sont migrĂ©s.

Pour commencer, vous devez exĂ©cuter un audit sans l’argument --config-file-path :

gh actions-importer audit gitlab --output-dir ./output/

La sortie de cette commande contient un fichier nommĂ© config.yml qui contient lui-mĂȘme une liste de toutes les actions composites qui ont Ă©tĂ© converties par GitHub Actions Importer. Par exemple, le fichier config.yml peut avoir le contenu suivant :

reusable_workflows:
  - name: my-reusable-workflow.yml
    target_url: https://github.com/octo-org/octo-repo
    ref: main

Vous pouvez utiliser ce fichier pour spĂ©cifier le rĂ©fĂ©rentiel et la rĂ©fĂ©rence auxquels un workflow rĂ©utilisable ou une action composite doit ĂȘtre ajoutĂ©. Vous pouvez ensuite utiliser l’argument --config-file-path pour fournir le fichier config.yml Ă  GitHub Actions Importer. Par exemple, vous pouvez utiliser ce fichier lors de l’exĂ©cution d’une commande migrate pour ouvrir une demande de tirage pour chaque rĂ©fĂ©rentiel unique dĂ©fini dans le fichier config :

gh actions-importer migrate gitlab --project my-project-name --output-dir output/ --config-file-path config.yml --target-url https://github.com/my-org/my-repo

Syntaxe prise en charge pour les pipelines GitLab

Le tableau suivant montre le type de propriĂ©tĂ©s que GitHub Actions Importer est en mesure de convertir. Pour plus d’informations sur l’alignement de la syntaxe des pipelines GitLab sur GitHub Actions, consultez « Migration de GitLab CI/CD vers GitHub Actions ».

Pipelines GitLabGitHub ActionsÉtat
after_scriptjobs.<job_id>.stepsPrise en charge
auto_cancel_pending_pipelinesconcurrencyPrise en charge
before_scriptjobs.<job_id>.stepsPrise en charge
build_timeout ou timeoutjobs.<job_id>.timeout-minutesPrise en charge
defaultNon applicablePrise en charge
imagejobs.<job_id>.containerPrise en charge
jobjobs.<job_id>Prise en charge
needsjobs.<job_id>.needsPrise en charge
only_allow_merge_if_pipeline_succeedson.pull_requestPrise en charge
resource_groupjobs.<job_id>.concurrencyPrise en charge
scheduleon.schedulePrise en charge
scriptjobs.<job_id>.stepsPrise en charge
stagesjobsPrise en charge
tagsjobs.<job_id>.runs-onPrise en charge
variablesenv, jobs.<job_id>.envPrise en charge
Exécuter des pipelines pour les nouvelles validationson.pushPrise en charge
Exécuter des pipelines manuellementon.workflow_dispatchPrise en charge
environmentjobs.<job_id>.environmentPartiellement pris en charge
includeLes fichiers rĂ©fĂ©rencĂ©s dans une instruction include sont fusionnĂ©s dans un graphique de travail unique avant d’ĂȘtre transformĂ©s.Partiellement pris en charge
only ou exceptjobs.<job_id>.ifPartiellement pris en charge
paralleljobs.<job_id>.strategyPartiellement prise en charge
rulesjobs.<job_id>.ifPartiellement prise en charge
servicesjobs.<job_id>.servicesPartiellement prise en charge
workflowifPartiellement pris en charge

Pour plus d’informations sur les constructions GitLab prises en charge, consultez le dĂ©pĂŽt github/gh-actions-importer.

Syntaxe des variables d’environnement

GitHub Actions Importer utilise le mappage dans le tableau ci-dessous pour convertir les variables d’environnement GitLab par dĂ©faut en l’équivalent le plus proche dans GitHub Actions.

GitLabGitHub Actions
CI_API_V4_URL${{ github.api_url }}
CI_BUILDS_DIR${{ github.workspace }}
CI_COMMIT_BRANCH${{ github.ref }}
CI_COMMIT_REF_NAME${{ github.ref }}
CI_COMMIT_REF_SLUG${{ github.ref }}
CI_COMMIT_SHA${{ github.sha }}
CI_COMMIT_SHORT_SHA${{ github.sha }}
CI_COMMIT_TAG${{ github.ref }}
CI_JOB_ID${{ github.job }}
CI_JOB_MANUAL${{ github.event_name == 'workflow_dispatch' }}
CI_JOB_NAME${{ github.job }}
CI_JOB_STATUS${{ job.status }}
CI_JOB_URL${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
CI_JOB_TOKEN${{ github.token }}
CI_NODE_INDEX${{ strategy.job-index }}
CI_NODE_TOTAL${{ strategy.job-total }}
CI_PIPELINE_ID${{ github.repository}}/${{ github.workflow }}
CI_PIPELINE_IID${{ github.workflow }}
CI_PIPELINE_SOURCE${{ github.event_name }}
CI_PIPELINE_TRIGGERED${{ github.actions }}
CI_PIPELINE_URL${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
CI_PROJECT_DIR${{ github.workspace }}
CI_PROJECT_ID${{ github.repository }}
CI_PROJECT_NAME${{ github.event.repository.name }}
CI_PROJECT_NAMESPACE${{ github.repository_owner }}
CI_PROJECT_PATH_SLUG${{ github.repository }}
CI_PROJECT_PATH${{ github.repository }}
CI_PROJECT_ROOT_NAMESPACE${{ github.repository_owner }}
CI_PROJECT_TITLE${{ github.event.repository.full_name }}
CI_PROJECT_URL${{ github.server_url }}/${{ github.repository }}
CI_REPOSITORY_URL${{ github.event.repository.clone_url }}
CI_RUNNER_EXECUTABLE_ARCH${{ runner.os }}
CI_SERVER_HOST${{ github.server_url }}
CI_SERVER_URL${{ github.server_url }}
CI_SERVER${{ github.actions }}
GITLAB_CI${{ github.actions }}
GITLAB_USER_EMAIL${{ github.actor }}
GITLAB_USER_ID${{ github.actor }}
GITLAB_USER_LOGIN${{ github.actor }}
GITLAB_USER_NAME${{ github.actor }}
TRIGGER_PAYLOAD${{ github.event_path }}
CI_MERGE_REQUEST_ASSIGNEES${{ github.event.pull_request.assignees }}
CI_MERGE_REQUEST_ID${{ github.event.pull_request.number }}
CI_MERGE_REQUEST_IID${{ github.event.pull_request.number }}
CI_MERGE_REQUEST_LABELS${{ github.event.pull_request.labels }}
CI_MERGE_REQUEST_MILESTONE${{ github.event.pull_request.milestone }}
CI_MERGE_REQUEST_PROJECT_ID${{ github.repository }}
CI_MERGE_REQUEST_PROJECT_PATH${{ github.repository }}
CI_MERGE_REQUEST_PROJECT_URL${{ github.server_url }}/${{ github.repository }}
CI_MERGE_REQUEST_REF_PATH${{ github.ref }}
CI_MERGE_REQUEST_SOURCE_BRANCH_NAME${{ github.event.pull_request.head.ref }}
CI_MERGE_REQUEST_SOURCE_BRANCH_SHA${{ github.event.pull_request.head.sha}}
CI_MERGE_REQUEST_SOURCE_PROJECT_ID${{ github.event.pull_request.head.repo.full_name }}
CI_MERGE_REQUEST_SOURCE_PROJECT_PATH${{ github.event.pull_request.head.repo.full_name }}
CI_MERGE_REQUEST_SOURCE_PROJECT_URL${{ github.event.pull_request.head.repo.url }}
CI_MERGE_REQUEST_TARGET_BRANCH_NAME${{ github.event.pull_request.base.ref }}
CI_MERGE_REQUEST_TARGET_BRANCH_SHA${{ github.event.pull_request.base.sha }}
CI_MERGE_REQUEST_TITLE${{ github.event.pull_request.title }}
CI_EXTERNAL_PULL_REQUEST_IID${{ github.event.pull_request.number }}
CI_EXTERNAL_PULL_REQUEST_SOURCE_REPOSITORY${{ github.event.pull_request.head.repo.full_name }}
CI_EXTERNAL_PULL_REQUEST_TARGET_REPOSITORY${{ github.event.pull_request.base.repo.full_name }}
CI_EXTERNAL_PULL_REQUEST_SOURCE_BRANCH_NAME${{ github.event.pull_request.head.ref }}
CI_EXTERNAL_PULL_REQUEST_SOURCE_BRANCH_SHA${{ github.event.pull_request.head.sha }}
CI_EXTERNAL_PULL_REQUEST_TARGET_BRANCH_NAME${{ github.event.pull_request.base.ref }}
CI_EXTERNAL_PULL_REQUEST_TARGET_BRANCH_SHA${{ github.event.pull_request.base.sha }}

Certaines parties ont été adaptées à partir de https://github.com/github/gh-actions-importer/ sous la licence MIT :

MIT License

Copyright (c) 2022 GitHub

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.