# Migration à partir de Azure DevOps avec GitHub Actions Importer Découvrez comment automatiser GitHub Actions Importer la migration de vos pipelines Azure DevOps vers GitHub Actions. ## À propos de la migration à partir de Azure DevOps avec GitHub Actions Importer Les instructions ci-dessous vous guident tout au long de la configuration de votre environnement à utiliser GitHub Actions Importer pour migrer Azure DevOps pipelines vers GitHub Actions. ### Prérequis * Un compte ou une organisation Azure DevOps avec des projets et des pipelines que vous souhaitez convertir en GitHub Actions flux de travail. * Accès pour créer un Azure DevOps personal access token pour votre compte ou votre organisation. * Un environnement dans lequel vous pouvez exécuter des conteneurs basés sur Linux et installer les outils nécessaires. * Docker est [installé](https://docs.docker.com/get-docker/) et en cours d’exécution. * L’[interface CLI GitHub](https://cli.github.com) est installée. > \[!NOTE] > 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 Importernécessite la version 5.0 de l’API Azure DevOps, disponible dans Azure DevOps Services ou Azure DevOps Server 2019. Les versions antérieures de 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 GitHub Actions Importer audit en tant que nom 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 Certains éléments d’Azure DevOps doivent être migrés manuellement depuis Azure DevOps dans les configurations GitHub Actions. Il s’agit notamment des paramètres suivants : * Secrets d’organisation, de dépôt et d’environnement * Connexions de service telles que OIDC Connect, GitHub Appset 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 de Azure Pipelines vers GitHub Actions](/fr/actions/tutorials/migrate-to-github-actions/manual-migrations/migrate-from-azure-pipelines) ». #### 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 GitHub Actions Importer CLI 1. Installez l’extension CLI GitHub Actions Importer : ```bash copy gh extension install github/gh-actions-importer ``` 2. Vérifiez que l’extension est installée : ```bash $ 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` permet de définir les informations d’identification et les options requises pour GitHub Actions Importer lors de l’utilisation d’Azure DevOps et de GitHub. 1. Créer un GitHubpersonal access token (classic). Pour plus d’informations, consultez « [Gestion de vos jetons d’accès personnels](/fr/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic) ». 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éez un Azure DevOps personal access token. Pour plus d’informations, consultez [Use personal access tokens](https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops\&tabs=Windows#create-a-pat) dans la documentation Azure DevOps. Le jeton doit avoir les périmètres suivants : * Pool d’agents : `Read` * Build : `Read` * Code : `Read` * Version publiée : `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. 3. Dans votre terminal, exécutez la GitHub Actions Importer`configure` commande CLI : ```shell 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 Space pour le sélectionner, puis appuyez sur Enter. * Pour «Personal access token pour GitHub », entrez la valeur du personal access token (classic) fichier que vous avez créé précédemment, 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 for Azure DevOps », entrez la valeur du Azure DevOps personal access token que vous avez créé précédemment, puis appuyez sur Entrée. * Pour « URL de base de l’instance de Azure DevOps », appuyez sur Enter pour accepter la valeur par défaut (`https://dev.azure.com`). * Pour « Azure DevOps nom de l’organisation », entrez le nom de votre organisation Azure DevOps, puis appuyez sur Enter. * Pour « Azure DevOps nom du projet », entrez le nom de votre projet Azure DevOps, puis appuyez sur Enter. Voici un exemple de la commande `configure` : ```shell $ 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. ``` 4. Dans votre terminal, exécutez la GitHub Actions Importer`update` commande CLI pour vous connecter à l’image GitHub PackagesContainer registry conteneur et vérifiez que l’image conteneur est mise à jour vers la dernière version : ```shell gh actions-importer update ``` La sortie de la commande devrait ressembler à la sortie ci-dessous : ```shell Updating ghcr.io/actions-importer/cli:latest... ghcr.io/actions-importer/cli:latest up-to-date ``` ## Effectuer un audit de Azure DevOps Vous pouvez utiliser la commande `audit` pour obtenir une vue générale de tous les projets d’une organisation Azure DevOps. La commande `audit` effectue les étapes suivantes : 1. Récupère tous les projets définis dans une organisation Azure DevOps. 2. Convertit chaque pipeline en flux de travail équivalent GitHub Actions . 3. Génère un rapport qui résume la façon dont l’exécution et la complexité d’une migration sont possibles avec GitHub Actions Importer. ### Exécution de la commande d'audit Pour effectuer un audit d’une organisation Azure DevOps, exécutez la commande suivante dans votre terminal : ```shell 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 de haut niveau 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** comportaient 100 % des composants du pipeline et des éléments individuels convertis automatiquement vers leur équivalent GitHub Actions. * ``` Les pipelines **partiellement convertis avec succès** ont vu toutes les constructions du pipeline converties, mais certains éléments individuels n'ont pas été convertis automatiquement vers 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** désigne une étape qui est soit : * Fondamentalement non pris 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 : * Si vous utilisez GitHub Enterprise Server, collecte de la liste des actions à synchroniser avec votre instance. * 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 qui GitHub Actions Importer ne sont pas en mesure de se terminer 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 défini au niveau du dépôt ou de l’organisation, 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](/fr/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets) ». * Un **exécuteur auto-hébergé** désigne un libellé d'exécuteur référencé dans un pipeline converti qui ne correspond 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 du 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'usage potentiel GitHub Actions Vous pouvez utiliser la commande pour prévoir l’utilisation `forecast` potentielle GitHub Actions en calculant les métriques à partir des exécutions de pipeline terminées dans Azure DevOps. ### Exécution de la commande de prévisions Pour effectuer une prévision de l’utilisation potentielle 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. ```shell 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 GitHubexécuteurs hébergés. ``` Cette métrique est liée au montant que vous devriez vous attendre à dépenser dans GitHub Actions. Cela varie en fonction du matériel utilisé pendant ces minutes. Vous pouvez utiliser la [GitHub Actions calculatrice de prix](https://github.com/pricing/calculator) 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 `dry-run` commande pour convertir un pipeline Azure DevOps en flux de travail équivalentGitHub Actions. 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. S’il existe quelque chose qui GitHub Actions Importer n’a pas été en mesure de convertir automatiquement, comme les é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 de GitHub Actions Importer avec des transformateurs personnalisés](/fr/actions/reference/github-actions-importer/custom-transformers) ». ### Exécution de la commande dry-run pour un pipeline de build Pour effectuer une exécution sèche de migration de votre pipeline de build Azure DevOps vers GitHub Actions, exécutez la commande suivante dans votre terminal, en `pipeline_id` remplaçant par l’ID du pipeline que vous convertissez. ```shell gh actions-importer dry-run azure-devops pipeline --pipeline-id :pipeline_id --output-dir tmp/dry-run ``` Vous pouvez afficher les journaux du 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 une exécution sèche de la migration de votre pipeline de mise en production Azure DevOps vers GitHub Actions, exécutez la commande suivante dans votre terminal, en `pipeline_id` remplaçant par l’ID du pipeline que vous convertissez. ```shell gh actions-importer dry-run azure-devops release --pipeline-id :pipeline_id --output-dir tmp/dry-run ``` Vous pouvez afficher les journaux du 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 pull request avec le flux de travail équivalent GitHub Actions. ### 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 par l’URL `target-url` de votre GitHub référentiel et `pipeline_id` par l’ID du pipeline que vous convertissez. ```shell 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 pull request qui ajoute le workflow converti à votre référentiel. Voici un exemple de sortie réussie : ```shell $ 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 déploiement 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 par l’URL `target-url` de votre GitHub référentiel et `pipeline_id` par l’ID du pipeline que vous convertissez. ```shell 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 pull request qui ajoute le workflow converti à votre référentiel. Voici un exemple de sortie réussie : ```shell $ 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 flux de travail à ajouter à votre référentiel GitHub. Une fois que vous avez terminé d’inspecter la demande de tirage, vous pouvez la fusionner pour ajouter le flux de travail à votre référentiel 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 GitHub Actions Importer de la migration à partir de 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](#configuring-credentials). GitHub Actions Importerutilise les variables d’environnement suivantes pour vous connecter à votre instance de Azure DevOps : * `GITHUB_ACCESS_TOKEN`: Le personal access token (classic) utilisé pour créer des pull requests avec un workflow converti (nécessite l’autorisation `workflow`). * `GITHUB_INSTANCE_URL`: URL de l’instance cible GitHub (par exemple, `https://github.com`). * `AZURE_DEVOPS_ACCESS_TOKEN` personal access token: utilisé pour s’authentifier auprès de votre instance de Azure DevOps. Ce jeton nécessite les étendues suivantes : * Build : `Read` * Pools d’agents : `Read` * Code : `Read` * Version publiée : `Read` * Connexions de service : `Read` * Groupes de tâches : `Read` * Groupe de variables : `Read` * `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 de l’organisation de votre instance de Azure DevOps. * `AZURE_DEVOPS_INSTANCE_URL` : URL de l’instance de Azure DevOps, telle que `https://dev.azure.com`. Ces variables d’environnement peuvent être spécifiées dans un fichier `.env.local` qui est 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 extrait le contenu du pipeline à partir du contrôle de code source. L’argument `--source-file-path` indique à GitHub Actions Importer d'utiliser à la place le chemin d’accès du fichier source spécifié. Par exemple : ```shell 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 extrait 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 d'Audit Dans cet exemple, GitHub Actions Importer utilise le fichier de configuration YAML spécifié comme fichier source pour effectuer un audit. ```shell 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 à l’aide d’un fichier de configuration, le fichier de configuration doit être au format suivant et chaque `repository_slug` doit être unique : ```yaml 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 de 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 sèche. 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é. ```shell 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 flux de travail réutilisables convertis et les actions composites sont migrés. Pour commencer, vous devez exécuter un audit sans l’argument `--config-file-path` : ```shell gh actions-importer audit azure-devops --output-dir ./output/ ``` La sortie de cette commande contient un fichier nommé `config.yml` qui contient une liste de tous les flux de travail réutilisables et actions composites qui ont été converties par GitHub Actions Importer. Par exemple, le fichier `config.yml` peut avoir le contenu suivant : ```yaml 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 `config.yml` fichier à GitHub Actions Importer. Par exemple, vous pouvez utiliser ce fichier lors de l'exécution d'une commande `migrate` pour ouvrir une pull request à chaque dépôt unique défini dans le fichier de configuration. ```shell 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 les types de propriétés que GitHub Actions Importer est actuellement en mesure de convertir. | Azure Pipelines | GitHub Actions | Statut | | :------------------- | :----------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------- | | condition | | Pris en charge | | conteneur | | Pris en charge | | intégration continue | | Pris en charge | | tâche | | Pris en charge | | pullRequest | | Pris en charge | | étape | | Pris en charge | | étapes | | Pris en charge | | stratégie | | Pris en charge | | délaiEnMinutes | | Pris en charge | | variables | | Pris 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 | | horaires | | Non pris en charge | | Déclencheurs | | Non pris en charge | Pour plus d’informations sur les tâches de Azure DevOps prises en charge, consultez le référentiel [`github/gh-actions-importer`](https://github.com/github/gh-actions-importer/blob/main/docs/azure_devops/index.md). ### Correspondances des variables d’environnement GitHub Actions Importerutilise le mappage dans le tableau ci-dessous pour convertir les variables d’environnement par défaut Azure DevOps en é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 Importerest en mesure de transformer des modèles Azure DevOps avec certaines limitations. * Les modèles Azure DevOps utilisés sous les clés `stages`, `deployments` et `jobs` sont convertis en flux de travail réutilisables dans GitHub Actions. Pour plus d’informations, consultez « [Réutiliser des workflows](/fr/actions/how-tos/reuse-automations/reuse-workflows) ». * Azure DevOps modèles utilisés sous la clé `steps` sont convertis en actions composites. Pour plus d’informations, consultez « [Création d’une action composite](/fr/actions/tutorials/create-actions/create-a-composite-action) ». * Si vous disposez actuellement de modèles de travail qui référencent d’autres modèles de travail, GitHub Actions Importer convertit les modèles en flux de travail réutilisables. Étant donné que les flux de travail réutilisables ne peuvent pas référencer d’autres flux de travail réutilisables, il s’agit d’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 ou GitHub référentiel de Azure DevOps externe, vous devez utiliser l’option `--credentials-file` permettant de fournir des informations d’identification pour accéder à ce modèle. Pour plus d’informations, consultez « [Arguments et paramètres supplémentaires](/fr/actions/reference/github-actions-importer/supplemental-arguments-and-settings#using-a-credentials-file-for-authentication) ». * 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 bloc `each` parent. * `each` et les conditions contenues `if` sont évaluées au moment de la transformation, car GitHub Actions ne prennent 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 blocs `if/elseif/else` imbriqués sous une condition `if` ne le sont pas. * `if` blocs qui utilisent des variables Azure DevOps prédéfinies ne sont pas pris en charge. #### Modèles pris en charge GitHub Actions Importer prend en charge les modèles répertoriés dans le tableau ci-dessous. | Azure Pipelines | GitHub Actions | Statut | | :---------------------------------------------------------------------------------- | :---------------------------------------- | ---------------------------: | | Extension à partir d’un modèle | `Reusable workflow` | Pris en charge | | Modèles de travail | `Reusable workflow` | Pris en charge | | Modèles de phase | `Reusable workflow` | Pris en charge | | Modèles d’étape | `Composite action` | Pris en charge | | Groupes de tâches dans l’éditeur classique | Variable | Pris en charge | | Modèles d’une organisation, d’un projet ou d’un référentiel différents Azure DevOps | Variable | Pris en charge | | Modèles dans un GitHub référentiel | Variable | Pris en charge | | Modèles de variables | `env` | Pris 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 fichiers relatifs ou dynamiques avec des expressions variables, de paramètres et itératives dans le nom de fichier. Toutefois, une valeur par défaut doit être définie. ##### Exemple de nom de fichier de chemin variable ```yaml # File: azure-pipelines.yml variables: - template: 'templates/vars.yml' steps: - template: "./templates/$" ``` ```yaml # File: templates/vars.yml variables: one: 'simple_step.yml' ``` ##### Exemple de nom de chemin de fichier de paramètre ```yaml parameters: - name: template type: string default: simple_step.yml steps: - template: "./templates/${{ parameters.template }}" ``` ##### Exemple de nom de chemin de fichier itératif ```yaml 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 répertoriés dans le tableau ci-dessous. | Azure Pipelines | GitHub Actions | Statut | | :------------------------------------------- | :--------------------------- | :--------------------------- | | string | `inputs.string` | Pris en charge | | nombre | `inputs.number` | Pris en charge | | booléen | `inputs.boolean` | Pris en charge | | objet | | | | `inputs.string` avec l’expression `fromJSON` | Partiellement pris en charge | | | étape | `step` | Partiellement pris en charge | | listeDesÉtapes | `step` | Partiellement pris en charge | | tâche | `job` | Partiellement pris en charge | | liste de tâches | `job` | Partiellement pris en charge | | déploiement | `job` | Partiellement pris en charge | | liste de déploiement | `job` | Partiellement pris en charge | | étape | `job` | Partiellement pris en charge | | listeDesÉtapes | `job` | Partiellement pris en charge | > \[!NOTE] > Un modèle utilisé sous la clé `step` avec ce type de paramètre n'est sérialisé en tant qu'action composite que 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 sous la licence MIT : ```text 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. ```