À propos de la migration depuis Azure DevOps 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 Azure DevOps vers GitHub Actions.
Prérequis
-
Un compte ou une organisation Azure DevOps avec des projets et des pipelines que vous souhaitez convertir en workflows GitHub Actions.
-
Accès pour créer un personal access token Azure DevOps 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.
- Docker est installé et en cours d’exécution.
- L’interface CLI GitHub est installée.
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
Il existe certaines limitations lors de la migration d’Azure DevOps vers GitHub Actions avec GitHub Actions Importer :
- GitHub Actions Importer nécessite la version 5.0 de l’API Azure DevOps, disponible dans Azure DevOps Services ou Azure DevOps Server 2019. Les versions antérieures d’Azure DevOps Server ne sont pas compatibles.
- Les tâches qui sont implicitement ajoutées à un pipeline Azure DevOps, telles que l’extraction du code source, peuvent être ajoutées à un audit GitHub Actions Importer en tant que nom de GUID. Pour trouver le nom de tâche convivial d’un GUID, vous pouvez utiliser l’URL suivante :
https://dev.azure.com/:organization/_apis/distributedtask/tasks/:guid
.
Tâches manuelles
Certaines constructions Azure DevOps doivent être migrées manuellement à partir d’Azure DevOps vers des configurations GitHub Actions. Il s’agit notamment des paramètres suivants :
- Secrets d’organisation, de dépôt et d’environnement
- Connexions de service comme OIDC Connect, GitHub Apps et personal access tokens
- Tâches inconnues
- Agents auto-hébergés
- Environnements
- Approbations pré-déploiement
Pour plus d’informations sur les migrations manuelles, consultez « Migration d’Azure Pipelines vers GitHub Actions ».
Tâches non prises en charge
GitHub Actions Importer ne prend pas en charge la migration des tâches suivantes :
- Portes pré-déploiement
- Portes post-déploiement
- Approbations post-déploiement
- Certains déclencheurs de ressources
Installation de l’extension CLI GitHub Actions Importer
-
Installez l’extension CLI GitHub Actions Importer :
Bash gh extension install github/gh-actions-importer
gh extension install github/gh-actions-importer
-
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 d’Azure DevOps et de GitHub.
-
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.
-
Créez un personal access token Azure DevOps. Pour plus d’informations, consultez Utiliser des personal access tokens dans la documentation Azure DevOps. Le jeton doit avoir les étendues suivantes :
- Pool d’agents :
Read
- Build :
Read
- Code :
Read
- Mise en production :
Read
- Connexions de service :
Read
- Groupes de tâches :
Read
- Groupe de variables :
Read
Après avoir créé le jeton, copiez-le et enregistrez-le en lieu sûr en vue de l’utiliser ultérieurement.
- Pool d’agents :
-
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
Azure DevOps
, 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 », appuyez sur Entrée pour accepter la valeur par défaut (
https://github.com
). - Pour « Personal access token pour Azure DevOps », entrez la valeur du personal access token Azure DevOps que vous avez créé, puis appuyez sur Entrée.
- Pour « URL de base de l’instance Azure DevOps », appuyez sur Entrée pour accepter la valeur par défaut (
https://dev.azure.com
). - Pour « Nom de l’organisation Azure DevOps », entrez le nom de votre organisation Azure DevOps et appuyez sur Entrée.
- Pour « Nom du projet Azure DevOps », entrez le nom de votre projet Azure DevOps et appuyez sur Entrée.
Voici un exemple de la commande
configure
:$ gh actions-importer configure ✔ Which CI providers are you configuring?: Azure DevOps Enter the following values (leave empty to omit): ✔ Personal access token for GitHub: *************** ✔ Base url of the GitHub instance: https://github.com ✔ Personal access token for Azure DevOps: *************** ✔ Base url of the Azure DevOps instance: https://dev.azure.com ✔ Azure DevOps organization name: :organization ✔ Azure DevOps project name: :project Environment variables successfully updated.
- Pour « Quels fournisseurs CI configurez-vous ? », utilisez les touches de direction pour sélectionner
-
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 d’Azure DevOps
Vous pouvez utiliser la commande audit
pour obtenir une vue d’ensemble de tous les projets d’une organisation Azure DevOps.
La commande audit
effectue les étapes suivantes :
- Récupère tous les projets définis dans une organisation Azure DevOps.
- Convertit chaque pipeline en son workflow GitHub Actions équivalent.
- Génère un rapport qui résume la complexité et l’exhaustivité d’une migration avec GitHub Actions Importer.
Exécution de la commande audit
Pour effectuer un audit d’une organisation Azure DevOps, exécutez la commande suivante dans votre terminal :
gh actions-importer audit azure-devops --output-dir tmp/audit
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é et n’était pas valide dans Bamboo.
- 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évision de l’utilisation potentielle de GitHub Actions
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 dans Azure DevOps.
Exécution de la commande forecast
Pour faire une prévision de l’utilisation potentielle de GitHub Actions, exécutez la commande suivante dans votre terminal. Par défaut, GitHub Actions Importer inclut les sept jours précédents dans le rapport de prévision.
gh actions-importer forecast azure-devops --output-dir tmp/forecast_reports
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 Azure DevOps. 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 un test de migration
Vous pouvez utiliser la commande dry-run
pour convertir un pipeline Azure DevOps 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 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 ».
Exécution de la commande dry-run pour un pipeline de build
Pour effectuer un test de migration de votre pipeline de build Azure DevOps vers GitHub Actions, exécutez la commande suivante dans votre terminal, en remplaçant pipeline_id
par l’ID du pipeline que vous convertissez.
gh actions-importer dry-run azure-devops pipeline --pipeline-id :pipeline_id --output-dir tmp/dry-run
Vous pouvez afficher les journaux de l’exécution test et les fichiers de workflow convertis dans le répertoire de sortie spécifié.
Exécution de la commande dry-run pour un pipeline de mise en production
Pour effectuer un test de migration de votre pipeline de mise en production Azure DevOps vers GitHub Actions, exécutez la commande suivante dans votre terminal, en remplaçant pipeline_id
par l’ID du pipeline que vous convertissez.
gh actions-importer dry-run azure-devops release --pipeline-id :pipeline_id --output-dir tmp/dry-run
Vous pouvez afficher les journaux de l’exécution test et les fichiers de workflow convertis dans le répertoire de sortie spécifié.
Effectuer une migration en production
Vous pouvez utiliser la commande migrate
pour convertir un pipeline Azure DevOps et ouvrir une demande de tirage avec le workflow GitHub Actions équivalent.
Exécution de la commande migrate pour un pipeline de build
Pour migrer un pipeline de build Azure DevOps vers GitHub Actions, exécutez la commande suivante dans votre terminal, en remplaçant la valeur target-url
par l’URL de votre dépôt GitHub et pipeline_id
par l’ID du pipeline que vous convertissez.
gh actions-importer migrate azure-devops pipeline --pipeline-id :pipeline_id --target-url https://github.com/octo-org/octo-repo --output-dir tmp/migrate
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 azure-devops pipeline --target-url https://github.com/octo-org/octo-repo --output-dir tmp/migrate --azure-devops-project my-azure-devops-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'
Exécution de la commande migrate pour un pipeline de mise en production
Pour migrer un pipeline de mise en production Azure DevOps vers GitHub Actions, exécutez la commande suivante dans votre terminal, en remplaçant la valeur target-url
par l’URL de votre dépôt GitHub et pipeline_id
par l’ID du pipeline que vous convertissez.
gh actions-importer migrate azure-devops release --pipeline-id :pipeline_id --target-url https://github.com/octo-org/octo-repo --output-dir tmp/migrate
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 azure-devops release --target-url https://github.com/octo-org/octo-repo --output-dir tmp/migrate --azure-devops-project my-azure-devops-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.
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.
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 d’Azure DevOps.
Variables d’environnement de configuration
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 Azure DevOps :
GITHUB_ACCESS_TOKEN
: personal access token (classic) utilisé pour créer des demandes de tirage avec un workflow converti (nécessite l’étendueworkflow
).GITHUB_INSTANCE_URL
: URL de l’instance GitHub cible (par exemple,https://github.com
).AZURE_DEVOPS_ACCESS_TOKEN
: personal access token utilisé pour vous authentifier auprès de votre instance Azure DevOps. Ce jeton nécessite les étendues suivantes :- Build :
Read
- Pools d’agents :
Read
- Code :
Read
- Mise en production :
Read
- Connexions de service :
Read
- Groupes de tâches :
Read
- Groupe de variables :
Read
- Build :
AZURE_DEVOPS_PROJECT
: Nom du projet ou GUID à utiliser lors de la migration d’un pipeline. Si vous souhaitez effectuer un audit sur tous les projets, elle est facultative.AZURE_DEVOPS_ORGANIZATION
: Nom d’organisation de votre instance Azure DevOps.AZURE_DEVOPS_INSTANCE_URL
: URL de l’instance Azure DevOps, par exemplehttps://dev.azure.com
.
Ces variables d’environnement peuvent être spécifiées dans un fichier .env.local
chargé par GitHub Actions Importer lors de son exécution.
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 azure-devops pipeline --output-dir ./output/ --source-file-path ./path/to/azure_devops/pipeline.yml
--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 ou une action composite converti doit être migré.
Exemple Audit
Dans cet exemple, GitHub Actions Importer utilise le fichier de configuration YAML spécifié comme fichier source pour effectuer un audit.
gh actions-importer audit azure-devops pipeline --output-dir ./output/ --config-file-path ./path/to/azure_devops/config.yml
Pour auditer une instance Azure DevOps avec un fichier de configuration, celui-ci doit être au format suivant et chaque repository_slug
doit être unique :
source_files:
- repository_slug: azdo-project/1
path: file.yml
- repository_slug: azdo-project/2
paths: path.yml
Vous pouvez générer le repository_slug
pour un pipeline en combinant le nom de l’organisation Azure DevOps, le nom du projet et l’ID du pipeline. Par exemple : my-organization-name/my-project-name/42
.
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 de l’option --azure-devops-organization
et --azure-devops-project
. path
est ensuite utilisé pour tirer (pull) le fichier source spécifié.
gh actions-importer dry-run azure-devops pipeline --output-dir ./output/ --config-file-path ./path/to/azure_devops/config.yml
Spécifier le référentiel des workflows réutilisables convertis et des actions composites
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 cet les actions composites convertis sont migrés.
Pour commencer, vous devez exécuter un audit sans l’argument --config-file-path
:
gh actions-importer audit azure-devops --output-dir ./output/
La sortie de cette commande contient un fichier nommé config.yml
qui contient lui-même une liste de tous les workflows réutilisables et actions composites qui ont été convertis 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
composite_actions:
- name: my-composite-action.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 azure-devops pipeline --config-file-path config.yml --target-url https://github.com/my-org/my-repo
Syntaxe prise en charge pour les pipelines Azure DevOps
Le tableau suivant montre le type de propriétés que GitHub Actions Importer peut actuellement convertir.
Azure Pipelines | GitHub Actions | Statut |
---|---|---|
condition |
| Prise en charge |
conteneur |
| Prise en charge |
continuousIntegration |
| Prise en charge |
travail |
| Prise en charge |
pullRequest |
| Prise en charge |
phase |
| Pris en charge |
steps |
| Prise en charge |
stratégie |
| Prise en charge |
timeoutInMinutes |
| Prise en charge |
variables |
| Prise en charge |
déploiement manuel |
| Partiellement pris en charge |
pool |
| Partiellement pris en charge |
services |
| Partiellement pris en charge |
stratégie |
| Partiellement pris en charge |
Déclencheurs |
| Partiellement pris en charge |
pullRequest |
| Non pris en charge |
schedules |
| Non pris en charge |
Déclencheurs |
| Non pris en charge |
Pour plus d’informations sur les tâches Azure DevOps prises en charge, consultez le dépôt github/gh-actions-importer
.
Correspondances des variables d’environnement
GitHub Actions Importer utilise les correspondances dans le tableau ci-dessous pour convertir les variables d’environnement Azure DevOps par défaut en l’équivalent le plus proche dans GitHub Actions.
Azure Pipelines | GitHub Actions |
---|---|
$(Agent.BuildDirectory) | ${{ runner.workspace }} |
$(Agent.HomeDirectory) | ${{ env.HOME }} |
$(Agent.JobName) | ${{ github.job }} |
$(Agent.OS) | ${{ runner.os }} |
$(Agent.ReleaseDirectory) | ${{ github.workspace}} |
$(Agent.RootDirectory) | ${{ github.workspace }} |
$(Agent.ToolsDirectory) | ${{ runner.tool_cache }} |
$(Agent.WorkFolder) | ${{ github.workspace }} |
$(Build.ArtifactStagingDirectory) | ${{ runner.temp }} |
$(Build.BinariesDirectory) | ${{ github.workspace }} |
$(Build.BuildId) | ${{ github.run_id }} |
$(Build.BuildNumber) | ${{ github.run_number }} |
$(Build.DefinitionId) | ${{ github.workflow }} |
$(Build.DefinitionName) | ${{ github.workflow }} |
$(Build.PullRequest.TargetBranch) | ${{ github.base_ref }} |
$(Build.PullRequest.TargetBranch.Name) | ${{ github.base_ref }} |
$(Build.QueuedBy) | ${{ github.actor }} |
$(Build.Reason) | ${{ github.event_name }} |
$(Build.Repository.LocalPath) | ${{ github.workspace }} |
$(Build.Repository.Name) | ${{ github.repository }} |
$(Build.Repository.Provider) | GitHub |
$(Build.Repository.Uri) | ${{ github.server.url }}/${{ github.repository }} |
$(Build.RequestedFor) | ${{ github.actor }} |
$(Build.SourceBranch) | ${{ github.ref }} |
$(Build.SourceBranchName) | ${{ github.ref }} |
$(Build.SourceVersion) | ${{ github.sha }} |
$(Build.SourcesDirectory) | ${{ github.workspace }} |
$(Build.StagingDirectory) | ${{ runner.temp }} |
$(Pipeline.Workspace) | ${{ runner.workspace }} |
$(Release.DefinitionEnvironmentId) | ${{ github.job }} |
$(Release.DefinitionId) | ${{ github.workflow }} |
$(Release.DefinitionName) | ${{ github.workflow }} |
$(Release.Deployment.RequestedFor) | ${{ github.actor }} |
$(Release.DeploymentID) | ${{ github.run_id }} |
$(Release.EnvironmentId) | ${{ github.job }} |
$(Release.EnvironmentName) | ${{ github.job }} |
$(Release.Reason) | ${{ github.event_name }} |
$(Release.RequestedFor) | ${{ github.actor }} |
$(System.ArtifactsDirectory) | ${{ github.workspace }} |
$(System.DefaultWorkingDirectory) | ${{ github.workspace }} |
$(System.HostType) | build |
$(System.JobId) | ${{ github.job }} |
$(System.JobName) | ${{ github.job }} |
$(System.PullRequest.PullRequestId) | ${{ github.event.number }} |
$(System.PullRequest.PullRequestNumber) | ${{ github.event.number }} |
$(System.PullRequest.SourceBranch) | ${{ github.ref }} |
$(System.PullRequest.SourceRepositoryUri) | ${{ github.server.url }}/${{ github.repository }} |
$(System.PullRequest.TargetBranch) | ${{ github.event.base.ref }} |
$(System.PullRequest.TargetBranchName) | ${{ github.event.base.ref }} |
$(System.StageAttempt) | ${{ github.run_number }} |
$(System.TeamFoundationCollectionUri) | ${{ github.server.url }}/${{ github.repository }} |
$(System.WorkFolder) | ${{ github.workspace }} |
Modèles
Vous pouvez transformer des modèles Azure DevOps avec GitHub Actions Importer.
Limites
GitHub Actions Importer peut transformer des modèles Azure DevOps avec certaines limitations.
- Les modèles Azure DevOps utilisés sous les clés
stages
,deployments
etjobs
sont convertis en workflows réutilisables dans GitHub Actions. Pour plus d’informations, consultez « Réutilisation des workflows ». - Les modèles Azure DevOps utilisés sous la clé
steps
sont convertis en actions composites. Pour plus d’informations, consultez « Création d’une action composite ». - Si vous avez actuellement des modèles de travail qui font référence à d’autres modèles de travail, GitHub Actions Importer les convertit en workflows réutilisables. Étant donné que les workflows réutilisables ne peuvent pas référencer d’autres workflows réutilisables, c’est une syntaxe non valide dans GitHub Actions. Vous devez corriger manuellement les workflows réutilisables imbriqués.
- Si un modèle fait référence à une organisation Azure DevOps externe ou un dépôt GitHub, vous devez utiliser l’option
--credentials-file
pour fournir des informations d’identification permettant d’accéder à ce modèle. Pour plus d’informations, consultez « Arguments et paramètres supplémentaires ». - Vous pouvez générer dynamiquement YAML en utilisant des expressions
each
avec les inconvénients suivants :- Les blocs
each
imbriqués ne sont pas pris en charge et entraînent la non-prise en charge du bloceach
parent. - Les conditions
each
etif
contenues sont évaluées au moment de la transformation, car GitHub Actions ne prend pas en charge ce style d’insertion. - Les blocs
elseif
ne sont pas pris en charge. Si cette fonctionnalité est requise, vous devez les corriger manuellement. - Les blocs
if
imbriqués sont pris en charge, mais les blocsif/elseif/else
imbriqués sous une conditionif
ne le sont pas. - Les blocs
if
qui utilisent des variables Azure DevOps prédéfinies ne sont pas pris en charge.
- Les blocs
Modèles pris en charge
GitHub Actions Importer prend en charge les modèles listés dans le tableau ci-dessous.
Azure Pipelines | GitHub Actions | Statut |
---|---|---|
Extension à partir d’un modèle | Reusable workflow | Prise en charge |
Modèles de travail | Reusable workflow | Prise en charge |
Modèles de phase | Reusable workflow | Prise en charge |
Modèles d’étape | Composite action | Prise en charge |
Groupes de tâches dans l’éditeur classique | Variable | Prise en charge |
Modèles dans une autre organisation, un autre projet ou un autre dépôt Azure DevOps | Variable | Prise en charge |
Modèles dans un dépôt GitHub | Variable | Pris en charge |
Modèles de variables | env | Prise en charge |
Insertion conditionnelle | Conditions if sur le travail/les étapes | Partiellement pris en charge |
Insertion itérative | Non applicable | Partiellement pris en charge |
Modèles avec paramètres | Variable | Partiellement pris en charge |
Noms du chemin de fichier des modèles
GitHub Actions Importer peut extraire des modèles avec des chemins de fichier relatifs ou dynamiques avec des variables, des paramètres et des expressions itératives dans le nom de fichier. Toutefois, une valeur par défaut doit être définie.
Exemple de nom de chemin de fichier de variable
# File: azure-pipelines.yml
variables:
- template: 'templates/vars.yml'
steps:
- template: "./templates/$"
# File: templates/vars.yml
variables:
one: 'simple_step.yml'
Exemple de nom de chemin de fichier de paramètre
parameters:
- name: template
type: string
default: simple_step.yml
steps:
- template: "./templates/${{ parameters.template }}"
Exemple de nom de chemin de fichier itératif
parameters:
- name: steps
type: object
default:
- build_step
- release_step
steps:
- ${{ each step in parameters.steps }}:
- template: "$-variables.yml"
Paramètres de modèle
GitHub Actions Importer prend en charge les paramètres listés dans le tableau ci-dessous.
Azure Pipelines | GitHub Actions | État |
---|---|---|
string | inputs.string | Prise en charge |
nombre | inputs.number | Prise en charge |
boolean | inputs.boolean | Prise en charge |
object | inputs.string avec l’expression fromJSON | Partiellement pris en charge |
étape | step | Partiellement pris en charge |
stepList | step | Partiellement pris en charge |
travail | job | Partiellement pris en charge |
jobList | job | Partiellement pris en charge |
deployment | job | Partiellement pris en charge |
deploymentList | job | Partiellement pris en charge |
phase | job | Partiellement pris en charge |
stageList | job | Partiellement pris en charge |
Remarque : Un modèle utilisé sous la clé step
avec ce type de paramètre est sérialisé en tant qu’action composite seulement si les étapes sont utilisées au début ou à la fin des étapes du modèle. Un modèle utilisé sous les clés stage
, deployment
et job
avec ce type de paramètre n’est pas transformé en workflow réutilisable, mais est sérialisé en tant que workflow autonome.
Mentions légales
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.