{"meta":{"title":"Migrando de Azure DevOps com o Importador de GitHub Actions","intro":"Saiba como usar GitHub Actions Importer para automatizar a migração de seus pipelines de Azure DevOps para GitHub Actions.","product":"GitHub Actions","breadcrumbs":[{"href":"/pt/actions","title":"GitHub Actions"},{"href":"/pt/actions/tutorials","title":"Tutoriais"},{"href":"/pt/actions/tutorials/migrate-to-github-actions","title":"Migrar para o GitHub Actions"},{"href":"/pt/actions/tutorials/migrate-to-github-actions/automated-migrations","title":"Migrações automatizadas"},{"href":"/pt/actions/tutorials/migrate-to-github-actions/automated-migrations/azure-devops-migration","title":"Migração do Azure DevOps"}],"documentType":"article"},"body":"# Migrando de Azure DevOps com o Importador de GitHub Actions\n\nSaiba como usar GitHub Actions Importer para automatizar a migração de seus pipelines de Azure DevOps para GitHub Actions.\n\n## Sobre a migração do Azure DevOps usando o Importador do GitHub Actions\n\nAs instruções a seguir orientarão você na configuração do seu ambiente para usar GitHub Actions Importer para migrar pipelines do Azure DevOps para GitHub Actions.\n\n### Pré-requisitos\n\n* Uma conta do Azure DevOps ou organização com projetos e pipelines que você deseja converter em fluxos de trabalho do GitHub Actions.\n* Acesso para criar um Azure DevOps personal access token para sua conta ou organização.\n* Um ambiente em que seja possível executar contêineres baseados no Linux e instalar as ferramentas necessárias.\n  * O Docker está [instalado](https://docs.docker.com/get-docker/) e em execução.\n\n  * A [CLI do GitHub](https://cli.github.com) está instalada.\n  > \\[!NOTE]\n  > A CLI e o contêiner do GitHub Actions Importer não precisam ser instalados no mesmo servidor que a plataforma de CI.\n\n### Limitações\n\nHá algumas limitações ao migrar de Azure DevOps para GitHub Actions comGitHub Actions Importer:\n\n* GitHub Actions Importerrequer a versão 5.0 da API Azure DevOps, disponível nos Serviços Azure DevOps ou no Azure DevOps Server 2019. Versões mais antigas de Azure DevOps Server não são compatíveis.\n* Tarefas que são adicionadas implicitamente a um pipeline de Azure DevOps, como verificar o código-fonte, podem ser adicionadas a uma auditoria do GitHub Actions Importer como um nome GUID. Para localizar o nome da tarefa amigável de um GUID, use a seguinte URL: `https://dev.azure.com/:organization/_apis/distributedtask/tasks/:guid`.\n\n#### Tarefas manuais\n\nDeterminados constructos de Azure DevOps devem ser migrados manualmente de Azure DevOps para GitHub Actions configurações. Estão incluídos:\n\n* Segredos de organização, repositório e ambiente\n* Conexões de serviço, como OIDC Connect, GitHub Apps e personal access tokens\n* Tarefas desconhecidas\n* Agentes auto-hospedados\n* Ambientes\n* Aprovações pré-implantação\n\nPara saber mais sobre migrações manuais, confira [Migrando de Azure Pipelines para GitHub Actions](/pt/actions/tutorials/migrate-to-github-actions/manual-migrations/migrate-from-azure-pipelines).\n\n#### Tarefas sem suporte\n\nGitHub Actions Importer não dá suporte à migração das seguintes tarefas:\n\n* Portões pré-implantação\n* Portões pós-implantação\n* Aprovações pós-implantação\n* Alguns gatilhos de recurso\n\n## Instalando a extensão da GitHub Actions Importer CLI\n\n1. Instale a extensão da CLI do GitHub Actions Importer:\n\n   ```bash copy\n   gh extension install github/gh-actions-importer\n   ```\n\n2. Verifique se a extensão foi instalada:\n\n   ```bash\n   $ gh actions-importer -h\n   Options:\n     -?, -h, --help  Show help and usage information\n\n   Commands:\n     update     Update to the latest version of GitHub Actions Importer.\n     version    Display the version of GitHub Actions Importer.\n     configure  Start an interactive prompt to configure credentials used to authenticate with your CI server(s).\n     audit      Plan your CI/CD migration by analyzing your current CI/CD footprint.\n     forecast   Forecast GitHub Actions usage from historical pipeline utilization.\n     dry-run    Convert a pipeline to a GitHub Actions workflow and output its yaml file.\n     migrate    Convert a pipeline to a GitHub Actions workflow and open a pull request with the changes.\n   ```\n\n## Como configurar credenciais\n\nO `configure` comando da CLI é usado para definir as credenciais e as opções necessárias para GitHub Actions Importer trabalhar com Azure DevOps e GitHub.\n\n1. Criar um GitHubpersonal access token (classic). Para saber mais, confira [Gerenciar seus tokens de acesso pessoal](/pt/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic).\n\n   O token precisa ter o escopo `workflow`.\n\n   Depois de criar o token, copie-o e salve-o em um local seguro para uso posterior.\n\n2. Criar um Azure DevOps personal access token. Para obter mais informações, consulte [Usar 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) na documentação do Azure DevOps. O token precisa ter os seguintes escopos:\n\n   * Pool de agentes: `Read`\n   * Construir: `Read`\n   * Código: `Read`\n   * Versão: `Read`\n   * Conexões de serviço: `Read`\n   * Grupos de tarefas: `Read`\n   * Grupo de variáveis: `Read`\n\n   Depois de criar o token, copie-o e salve-o em um local seguro para uso posterior.\n\n3. No seu terminal, execute o comando CLI GitHub Actions Importer`configure`:\n\n   ```shell\n   gh actions-importer configure\n   ```\n\n   O comando `configure` solicitará que você insira as seguintes informações:\n\n   * Em \"Quais provedores de CI você está configurando?\", use as teclas de direção para selecionar `Azure DevOps`, pressione <kbd>Space</kbd> para selecioná-lo e pressione <kbd>Enter</kbd>.\n   * Para \"Personal access token para GitHub\", insira o valor do personal access token (classic) que você criou anteriormente e pressione <kbd>Enter</kbd>.\n   * Para \"URL base da instância do GitHub\", insira pressione <kbd>Enter</kbd> para aceitar o valor padrão (`https://github.com`).\n   * Para \"Personal access token para Azure DevOps\", insira o valor do Azure DevOps personal access token que você criou anteriormente e pressione <kbd>Enter</kbd>.\n   * Para \"URL base da instância Azure DevOps\", pressione <kbd>Enter</kbd> para aceitar o valor padrão (`https://dev.azure.com`).\n   * Para \"Azure DevOps nome da organização\", insira o nome da sua organização Azure DevOps e pressione <kbd>Enter</kbd>.\n   * Para \"Azure DevOps nome do projeto\", insira o nome do projeto Azure DevOps e pressione <kbd>Enter</kbd>.\n\n   Um exemplo do comando `configure` é mostrado abaixo:\n\n   ```shell\n   $ gh actions-importer configure\n   ✔ Which CI providers are you configuring?: Azure DevOps\n   Enter the following values (leave empty to omit):\n   ✔ Personal access token for GitHub: ***************\n   ✔ Base url of the GitHub instance: https://github.com\n   ✔ Personal access token for Azure DevOps: ***************\n   ✔ Base url of the Azure DevOps instance: https://dev.azure.com\n   ✔ Azure DevOps organization name: :organization\n   ✔ Azure DevOps project name: :project\n   Environment variables successfully updated.\n   ```\n\n4. No terminal, execute o comando CLI GitHub Actions Importer`update` para se conectar ao GitHub PackagesContainer registry e garantir que a imagem do contêiner esteja atualizada para a versão mais recente:\n\n   ```shell\n   gh actions-importer update\n   ```\n\n   A saída do comando será semelhante ao seguinte:\n\n   ```shell\n   Updating ghcr.io/actions-importer/cli:latest...\n   ghcr.io/actions-importer/cli:latest up-to-date\n   ```\n\n## Executar uma auditoria de Azure DevOps\n\nVocê pode usar o comando `audit` para obter uma exibição de alto nível de todos os projetos em uma organização Azure DevOps.\n\nO comando `audit` executa as seguintes etapas:\n\n1. Busca todos os projetos definidos em uma organização Azure DevOps.\n2. Converte cada pipeline em seu fluxo de trabalho equivalente GitHub Actions .\n3. Gera um relatório que resume o quão completa e complexa de uma migração é possível com GitHub Actions Importer.\n\n### Como executar o comando de auditoria\n\nPara executar uma auditoria de uma organização Azure DevOps, execute o seguinte comando em seu terminal:\n\n```shell\ngh actions-importer audit azure-devops --output-dir tmp/audit\n```\n\n### Como inspecionar os resultados da auditoria\n\nOs arquivos do diretório de saída especificado contêm os resultados da auditoria. Confira o arquivo `audit_summary.md` para ver um resumo dos resultados da auditoria.\n\nO resumo da auditoria contém as seções a seguir.\n\n#### Pipelines\n\nA seção \"Pipelines\" contém estatísticas gerais sobre a taxa de conversão realizada por GitHub Actions Importer.\n\nVeja abaixo alguns termos importantes que podem aparecer na seção \"Pipelines\":\n\n* **Pipelines bem-sucedidos** tiveram 100% dos componentes do pipeline e itens individuais convertidos automaticamente para seus equivalentes GitHub Actions.\n* **Pipelines parcialmente bem-sucedidos** tiveram todos os constructos de pipeline convertidos, no entanto, havia alguns itens individuais que não foram convertidos automaticamente em seu GitHub Actions equivalente.\n* **Pipelines sem suporte** são tipos de definição que não têm suporte GitHub Actions Importer.\n* Pipelines **com falha** apresentaram um erro fatal durante a conversão. Isso pode ocorrer por uma das seguintes razões:\n  * O pipeline foi originalmente configurado incorretamente e era inválido.\n  * GitHub Actions Importer encontrou um erro interno ao convertê-lo.\n  * Houve uma resposta de rede malsucedida que tornou o pipeline inacessível, o que geralmente ocorre devido a credenciais inválidas.\n\n#### Etapas de compilação\n\nA seção \"Etapas de compilação\" contém uma visão geral das etapas de compilação individuais usadas em todos os pipelines e de quantas delas foram convertidas automaticamente por GitHub Actions Importer.\n\nA seguir estão alguns termos-chave que podem aparecer na seção \"Build steps\":\n\n* Uma etapa de compilação **conhecida** foi convertida automaticamente em uma ação equivalente.\n* Uma etapa de compilação **desconhecida** não foi convertida automaticamente em uma ação equivalente.\n* Uma etapa de compilação **sem suporte** é aquela que:\n  * Fundamentalmente não suportado por GitHub Actions.\n  * Configurado de uma maneira incompatível com GitHub Actions.\n* Uma **ação** é uma lista das ações que foram usadas nos fluxos de trabalho convertidos. Isso pode ser importante para:\n  * Se você usar GitHub Enterprise Server, reunindo a lista de ações para sincronizar com sua instância.\n  * Definir uma lista de permissões em nível organizacional para as ações utilizadas. Essa lista de ações é abrangente e inclui as ações que as equipes de segurança ou conformidade podem precisar analisar.\n\n#### Tarefas manuais\n\nA seção \"Tarefas manuais\" contém uma visão geral das tarefas que GitHub Actions Importer não podem ser concluídas automaticamente e que você deve concluir manualmente.\n\nVeja abaixo alguns termos importantes que podem aparecer na seção \"Tarefas manuais\":\n\n* Um **segredo** é um segredo no nível do repositório ou da organização que é usado nos pipelines convertidos. Esses segredos devem ser criados manualmente no GitHub Actions para que esses pipelines funcionem corretamente. Para saber mais, confira [Usar segredos em ações do GitHub](/pt/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets).\n* Um **executor auto-hospedado refere-se** a um rótulo de um executor que é referenciado em um pipeline convertido que não é um GitHubexecutor hospedado. Será necessário definir manualmente esses executores para que os pipelines funcionem de maneira correta.\n\n#### Arquivos\n\nA seção final do relatório de auditoria fornece um manifesto de todos os arquivos que foram gravados em disco durante a auditoria.\n\nCada arquivo de pipeline tem diversos arquivos incluídos na auditoria, incluindo:\n\n* O pipeline original como ele foi definido em GitHub.\n* Todas as respostas de rede usadas para converter o pipeline.\n* O arquivo de fluxo de trabalho convertido.\n* Rastros de pilha que podem ser usados para solucionar problemas em uma falha na conversão de um pipeline.\n\nAlém disso, o arquivo `workflow_usage.csv` contém uma lista separada por vírgula de todas as ações, todos os segredos e todos os executores usados pelos pipelines convertidos com sucesso. Isso pode ser útil para determinar quais fluxos de trabalho usam quais ações, segredos ou executores e para executar revisões de segurança.\n\n## Previsão de uso potencial GitHub Actions\n\nVocê pode usar o comando para prever o `forecast` uso potencial GitHub Actions calculando métricas de execuções de pipeline concluídas em Azure DevOps.\n\n### Como executar o comando de previsão\n\nPara executar uma previsão de uso potencial GitHub Actions , execute o comando a seguir em seu terminal. Por padrão, GitHub Actions Importer inclui os sete dias anteriores no relatório de previsão.\n\n```shell\ngh actions-importer forecast azure-devops --output-dir tmp/forecast_reports\n```\n\n### Como inspecionar o relatório de previsão\n\nO arquivo `forecast_report.md` no diretório de saída especificado contém os resultados da previsão.\n\nVeja abaixo alguns termos importantes que podem aparecer no relatório de previsão:\n\n* A **contagem de trabalhos** é o número total de trabalhos concluídos.\n* A **contagem de pipelines** é o número de pipelines exclusivos usados.\n* O **tempo de execução** descreve a quantidade de tempo que um executor gastou na execução de uma tarefa. Essa métrica pode ser usada para ajudar a planejar o custo dos GitHubexecutores hospedados.\n\n  Essa métrica está correlacionada ao quanto você deve esperar gastar no GitHub Actions. Isso pode variar de acordo com o hardware usado para esses minutos. Você pode usar a [GitHub Actions calculadora de preços](https://github.com/pricing/calculator) para estimar os custos.\n* ```\n            As métricas de **tempo de espera** descrevem o tempo gasto por um trabalho aguardando um executor ficar disponível para executá-lo.\n  ```\n* As métricas de **trabalhos simultâneos** descrevem a quantidade de trabalhos em execução a qualquer momento. Esta métrica pode ser usada para definir o número de executores que você deve configurar.\n\nAlém disso, essas métricas são definidas para cada fila de corredores em Azure DevOps. Isso é especialmente útil quando há uma combinação de executores hospedados ou auto-hospedados ou quando há computadores de especificação alta ou baixa, a fim de ver métricas específicas para diferentes tipos de executores.\n\n## Realizar uma simulação de migração\n\nVocê pode usar o `dry-run` comando para converter um pipeline de Azure DevOps em um fluxo de trabalho equivalenteGitHub Actions. Uma simulação cria os arquivos de saída em um diretório especificado, mas não abre uma solicitação de pull para migrar o pipeline.\n\nSe houver algo que GitHub Actions Importer não foi capaz de converter automaticamente, como etapas de build desconhecidas ou um pipeline parcialmente bem-sucedido, talvez você queira criar transformadores personalizados para personalizar ainda mais o processo de conversão. Para saber mais, confira [Estendendo o Importador do GitHub Actions com transformadores personalizados](/pt/actions/reference/github-actions-importer/custom-transformers).\n\n### Como executar o comando de 'dry-run' para um pipeline de build\n\nPara executar uma simulação de migração do pipeline de build do Azure DevOps para o GitHub Actions, execute o comando a seguir no terminal, substituindo `pipeline_id` pela ID do pipeline que você está convertendo.\n\n```shell\ngh actions-importer dry-run azure-devops pipeline --pipeline-id :pipeline_id --output-dir tmp/dry-run\n```\n\nÉ possível ver os logs da simulação e os arquivos de fluxos de trabalho convertidos no diretório de saída especificado.\n\n### Como executar o comando de simulação para um pipeline de lançamento\n\nPara executar uma execução seca de migração para o pipeline GitHub Actionsde lançamento do Azure DevOps, execute o seguinte comando em seu terminal, substituindo `pipeline_id` pela ID do pipeline que você está convertendo.\n\n```shell\ngh actions-importer dry-run azure-devops release --pipeline-id :pipeline_id --output-dir tmp/dry-run\n```\n\nÉ possível ver os logs da simulação e os arquivos de fluxos de trabalho convertidos no diretório de saída especificado.\n\n## Executar uma migração de produção\n\nVocê pode usar o comando `migrate` para converter um pipeline do Azure DevOps e abrir uma pull request com o fluxo de trabalho GitHub Actions equivalente.\n\n### Como executar o comando de migração para um pipeline de build\n\nPara migrar um pipeline de build do Azure DevOps para GitHub Actions, execute o seguinte comando no seu terminal, substituindo o valor de `target-url` pela URL do seu repositório do GitHub, e `pipeline_id` pelo ID do pipeline que você está convertendo.\n\n```shell\ngh actions-importer migrate azure-devops pipeline --pipeline-id :pipeline_id --target-url https://github.com/octo-org/octo-repo --output-dir tmp/migrate\n```\n\nA saída do comando inclui a URL da solicitação de pull que adiciona o fluxo de trabalho convertido ao repositório. Um exemplo de uma saída bem-sucedida é semelhante ao seguinte:\n\n```shell\n$ 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\n[2022-08-20 22:08:20] Logs: 'tmp/migrate/log/actions-importer-20220916-014033.log'\n[2022-08-20 22:08:20] Pull request: 'https://github.com/octo-org/octo-repo/pull/1'\n```\n\n### Como executar o comando de migração para um pipeline de release\n\nPara migrar um pipeline de release do Azure DevOps para GitHub Actions, execute o seguinte comando no terminal, substituindo o valor de `target-url` pela URL do seu repositório GitHub e `pipeline_id` pelo ID do pipeline que você está convertendo.\n\n```shell\ngh actions-importer migrate azure-devops release --pipeline-id :pipeline_id --target-url https://github.com/octo-org/octo-repo --output-dir tmp/migrate\n```\n\nA saída do comando inclui a URL da solicitação de pull que adiciona o fluxo de trabalho convertido ao repositório. Um exemplo de uma saída bem-sucedida é semelhante ao seguinte:\n\n```shell\n$ 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\n[2022-08-20 22:08:20] Logs: 'tmp/migrate/log/actions-importer-20220916-014033.log'\n[2022-08-20 22:08:20] Pull request: 'https://github.com/octo-org/octo-repo/pull/1'\n```\n\n### Como inspecionar a solicitação de pull\n\nA saída de uma execução bem-sucedida do comando `migrate` contém um link para a nova solicitação de pull que adiciona o fluxo de trabalho convertido ao seu repositório.\n\nAlguns elementos importantes da solicitação de pull incluem:\n\n* Na descrição da solicitação de pull, uma seção chamada **Etapas manuais**, que lista as etapas que você precisa concluir manualmente para concluir a migração dos pipelines para o GitHub Actions. Por exemplo, esta seção pode solicitar a criação dos segredos usados nos fluxos de trabalho.\n* O arquivo de fluxos de trabalho convertido. Selecione a guia **Files changed** na pull request para ver o arquivo de fluxo de trabalho que será adicionado ao repositório do GitHub.\n\nQuando terminar de inspecionar a pull request, você poderá mesclá-la para adicionar o fluxo de trabalho ao repositório do GitHub.\n\n## Referência\n\nEsta seção contém informações de referência sobre variáveis de ambiente, argumentos opcionais e sintaxe suportada ao usar GitHub Actions Importer para migrar do Azure DevOps.\n\n### Variáveis de ambiente da configuração\n\nO GitHub Actions Importer usa variáveis de ambiente para a configuração de autenticação. Essas variáveis são definidas durante o processo de configuração com o comando `configure`. Para obter mais informações, confira a seção [Como configurar as credenciais](#configuring-credentials).\n\nGitHub Actions Importerusa as seguintes variáveis de ambiente para se conectar à instância de Azure DevOps:\n\n* `GITHUB_ACCESS_TOKEN`: o personal access token (classic) usado para criar pull requests com um fluxo de trabalho convertido (requer o escopo do `workflow`).\n* `GITHUB_INSTANCE_URL`: a URL para a instância de destino GitHub (por exemplo, `https://github.com`).\n* `AZURE_DEVOPS_ACCESS_TOKEN`: o personal access token usado para autenticar com sua instância de Azure DevOps. Esse token exige os seguintes escopos:\n  * Construir: `Read`\n  * Pools de agentes: `Read`\n  * Código: `Read`\n  * Versão: `Read`\n  * Conexões de serviço: `Read`\n  * Grupos de tarefas: `Read`\n  * Grupo de variáveis: `Read`\n* `AZURE_DEVOPS_PROJECT`: O nome ou GUID do projeto a ser usado ao migrar um pipeline. Caso você deseje executar uma auditoria em todos os projetos, isso é opcional.\n* `AZURE_DEVOPS_ORGANIZATION`: o nome da organização de sua instância de Azure DevOps.\n* `AZURE_DEVOPS_INSTANCE_URL`: a URL para a instância de Azure DevOps, como `https://dev.azure.com`.\n\nEssas variáveis de ambiente podem ser especificadas em um `.env.local` arquivo que é carregado pelo GitHub Actions Importer quando ele é executado.\n\n### Argumentos opcionais\n\nHá argumentos opcionais que você pode usar com os subcomandos do GitHub Actions Importer para personalizar sua migração.\n\n#### `--source-file-path`\n\nUse o argumento `--source-file-path` com os subcomandos `forecast`, `dry-run` ou `migrate`.\n\nPor padrão, o GitHub Actions Importer busca o conteúdo do pipeline do controle do código-fonte. O argumento `--source-file-path` informa ao GitHub Actions Importer que use o caminho do arquivo de origem especificado.\n\nPor exemplo:\n\n```shell\ngh actions-importer dry-run azure-devops pipeline --output-dir ./output/ --source-file-path ./path/to/azure_devops/pipeline.yml\n```\n\n#### `--config-file-path`\n\nUse o argumento `--config-file-path` com os subcomandos `audit`, `dry-run` e `migrate`.\n\nPor padrão, o GitHub Actions Importer busca o conteúdo do pipeline do controle do código-fonte. O argumento `--config-file-path` instrui GitHub Actions Importer a usar os arquivos de origem especificados.\n\nO argumento `--config-file-path` também pode ser usado para especificar para qual repositório um fluxo de trabalho reutilizável convertido ou uma ação composta deve ser migrada.\n\n##### Exemplo de auditoria\n\nNeste exemplo, GitHub Actions Importer usa o arquivo de configuração YAML especificado como o arquivo de origem para executar uma auditoria.\n\n```shell\ngh actions-importer audit azure-devops pipeline --output-dir ./output/ --config-file-path ./path/to/azure_devops/config.yml\n```\n\nPara auditar uma instância Azure DevOps usando um arquivo de configuração, o arquivo de configuração deve estar no seguinte formato e cada `repository_slug` deve ser exclusivo:\n\n```yaml\nsource_files:\n  - repository_slug: azdo-project/1\n    path: file.yml\n  - repository_slug: azdo-project/2\n    paths: path.yml\n```\n\nVocê pode gerar o `repository_slug` para um pipeline combinando o nome da organização Azure DevOps, o nome do projeto e a ID do pipeline. Por exemplo, `my-organization-name/my-project-name/42`.\n\n##### Exemplo de simulação a seco\n\nNeste exemplo, GitHub Actions Importer usa o arquivo de configuração YAML especificado como o arquivo de origem para executar uma execução seca.\n\nO pipeline é selecionado pela correspondência do `repository_slug` no arquivo de configuração com o valor das opções `--azure-devops-organization` e `--azure-devops-project`. Em seguida, `path` é usado para efetuar pull do arquivo de origem especificado.\n\n```shell\ngh actions-importer dry-run azure-devops pipeline --output-dir ./output/ --config-file-path ./path/to/azure_devops/config.yml\n```\n\n##### Especificar o repositório de fluxos de trabalho reutilizáveis convertidos e ações compostas\n\nGitHub Actions Importer usa o arquivo YAML fornecido para o `--config-file-path` argumento para determinar o repositório para o qual os fluxos de trabalho reutilizáveis convertidos e as ações compostas são migrados.\n\nPara começar, você deve executar uma auditoria sem o argumento `--config-file-path`:\n\n```shell\ngh actions-importer audit azure-devops --output-dir ./output/\n```\n\nA saída desse comando conterá um arquivo nomeado `config.yml` que contém uma lista de todos os fluxos de trabalho reutilizáveis e ações compostas que foram convertidas por GitHub Actions Importer. Por exemplo, o arquivo `config.yml` pode ter o seguinte conteúdo:\n\n```yaml\nreusable_workflows:\n  - name: my-reusable-workflow.yml\n    target_url: https://github.com/octo-org/octo-repo\n    ref: main\n\ncomposite_actions:\n  - name: my-composite-action.yml\n    target_url: https://github.com/octo-org/octo-repo\n    ref: main\n```\n\nVocê pode usar esse arquivo para especificar a qual repositório e ref um fluxo de trabalho reutilizável ou uma ação composta deve ser adicionado. Em seguida, você pode usar o `--config-file-path` argumento para fornecer o `config.yml` arquivo para GitHub Actions Importer. Por exemplo, você pode usar esse arquivo ao executar um comando `migrate` para abrir uma solicitação de pull para cada repositório exclusivo definido no arquivo de configuração:\n\n```shell\ngh actions-importer migrate azure-devops pipeline --config-file-path config.yml --target-url https://github.com/my-org/my-repo\n```\n\n### Sintaxe suportada para pipelines do Azure DevOps\n\nA tabela a seguir mostra o tipo de propriedades que GitHub Actions Importer atualmente é capaz de converter.\n\n| Azure Pipelines     | GitHub Actions                                                                                                                             | Status          |\n| :------------------ | :----------------------------------------------------------------------------------------------------------------------------------------- | :-------------- |\n| condição            | <ul><li>`jobs.<job_id>.if`</li><li>`jobs.<job_id>.steps[*].if`</li></ul>                                                                   | Com suporte     |\n| contêiner           | <ul><li>`jobs.<job_id>.container`</li><li>`jobs.<job_id>.name`</li></ul>                                                                   | Com suporte     |\n| integração contínua | <ul><li>`on.<push>.<branches>`</li><li>`on.<push>.<tags>`</li><li>`on.<push>.paths`</li></ul>                                              | Com suporte     |\n| cargo               | <ul><li>`jobs.<job_id>`</li></ul>                                                                                                          | Com suporte     |\n| solicitação de pull | <ul><li>`on.<pull_request>.<branches>`</li><li>`on.<pull_request>.paths`</li></ul>                                                         | Com suporte     |\n| fase                | <ul><li>`jobs`</li></ul>                                                                                                                   | Com suporte     |\n| etapas              | <ul><li>`jobs.<job_id>.steps`</li></ul>                                                                                                    | Com suporte     |\n| estratégia          | <ul><li>`jobs.<job_id>.strategy.fail-fast`</li><li>`jobs.<job_id>.strategy.max-parallel`</li><li>`jobs.<job_id>.strategy.matrix`</li></ul> | Com suporte     |\n| timeoutInMinutes    | <ul><li>`jobs.<job_id>.timeout-minutes`</li></ul>                                                                                          | Com suporte     |\n| variáveis           | <ul><li>`env`</li><li>`jobs.<job_id>.env`</li><li>`jobs.<job_id>.steps.env`</li></ul>                                                      | Com suporte     |\n| implantação manual  | <ul><li>`jobs.<job_id>.environment`</li></ul>                                                                                              | Suporte parcial |\n| pool                | <ul><li>`runners`</li><li>`self hosted runners`</li></ul>                                                                                  | Suporte parcial |\n| serviços            | <ul><li>`jobs.<job_id>.services`</li></ul>                                                                                                 | Suporte parcial |\n| estratégia          | <ul><li>`jobs.<job_id>.strategy`</li></ul>                                                                                                 | Suporte parcial |\n| disparadores        | <ul><li>`on`</li></ul>                                                                                                                     | Suporte parcial |\n| solicitação de pull | <ul><li>`on.<pull_request>.<tags>`</li></ul>                                                                                               | Sem suporte     |\n| schedules           | <ul><li>`on.schedule`</li><li>`on.workflow_run`</li></ul>                                                                                  | Sem suporte     |\n| disparadores        | <ul><li>`on.<event_name>.types`</li></ul>                                                                                                  | Sem suporte     |\n\nPara obter mais informações sobre tarefas de Azure DevOps com suporte, consulte o [`github/gh-actions-importer` repositório](https://github.com/github/gh-actions-importer/blob/main/docs/azure_devops/index.md).\n\n### Mapeamento de variáveis de ambiente\n\nGitHub Actions Importerusa o mapeamento na tabela abaixo para converter variáveis de ambiente padrão Azure DevOps para o equivalente mais próximo em GitHub Actions.\n\n| Azure Pipelines                             | GitHub Actions                                      |\n| :------------------------------------------ | :-------------------------------------------------- |\n| `$(Agent.BuildDirectory)`                   | `${{ runner.workspace }}`                           |\n| `$(Agent.HomeDirectory)`                    | `${{ env.HOME }}`                                   |\n| `$(Agent.JobName)`                          | `${{ github.job }}`                                 |\n| `$(Agent.OS)`                               | `${{ runner.os }}`                                  |\n| `$(Agent.ReleaseDirectory)`                 | `${{ github.workspace}}`                            |\n| `$(Agent.RootDirectory)`                    | `${{ github.workspace }}`                           |\n| `$(Agent.ToolsDirectory)`                   | `${{ runner.tool_cache }}`                          |\n| `$(Agent.WorkFolder)`                       | `${{ github.workspace }}`                           |\n| `$(Build.ArtifactStagingDirectory)`         | `${{ runner.temp }}`                                |\n| `$(Build.BinariesDirectory)`                | `${{ github.workspace }}`                           |\n| `$(Build.BuildId)`                          | `${{ github.run_id }}`                              |\n| `$(Build.BuildNumber)`                      | `${{ github.run_number }}`                          |\n| `$(Build.DefinitionId)`                     | `${{ github.workflow }}`                            |\n| `$(Build.DefinitionName)`                   | `${{ github.workflow }}`                            |\n| `$(Build.PullRequest.TargetBranch)`         | `${{ github.base_ref }}`                            |\n| `$(Build.PullRequest.TargetBranch.Name)`    | `${{ github.base_ref }}`                            |\n| `$(Build.QueuedBy)`                         | `${{ github.actor }}`                               |\n| `$(Build.Reason)`                           | `${{ github.event_name }}`                          |\n| `$(Build.Repository.LocalPath)`             | `${{ github.workspace }}`                           |\n| `$(Build.Repository.Name)`                  | `${{ github.repository }}`                          |\n| `$(Build.Repository.Provider)`              | `GitHub`                                            |\n| `$(Build.Repository.Uri)`                   | `${{ github.server.url }}/${{ github.repository }}` |\n| `$(Build.RequestedFor)`                     | `${{ github.actor }}`                               |\n| `$(Build.SourceBranch)`                     | `${{ github.ref }}`                                 |\n| `$(Build.SourceBranchName)`                 | `${{ github.ref }}`                                 |\n| `$(Build.SourceVersion)`                    | `${{ github.sha }}`                                 |\n| `$(Build.SourcesDirectory)`                 | `${{ github.workspace }}`                           |\n| `$(Build.StagingDirectory)`                 | `${{ runner.temp }}`                                |\n| `$(Pipeline.Workspace)`                     | `${{ runner.workspace }}`                           |\n| `$(Release.DefinitionEnvironmentId)`        | `${{ github.job }}`                                 |\n| `$(Release.DefinitionId)`                   | `${{ github.workflow }}`                            |\n| `$(Release.DefinitionName)`                 | `${{ github.workflow }}`                            |\n| `$(Release.Deployment.RequestedFor)`        | `${{ github.actor }}`                               |\n| `$(Release.DeploymentID)`                   | `${{ github.run_id }}`                              |\n| `$(Release.EnvironmentId)`                  | `${{ github.job }}`                                 |\n| `$(Release.EnvironmentName)`                | `${{ github.job }}`                                 |\n| `$(Release.Reason)`                         | `${{ github.event_name }}`                          |\n| `$(Release.RequestedFor)`                   | `${{ github.actor }}`                               |\n| `$(System.ArtifactsDirectory)`              | `${{ github.workspace }}`                           |\n| `$(System.DefaultWorkingDirectory)`         | `${{ github.workspace }}`                           |\n| `$(System.HostType)`                        | `build`                                             |\n| `$(System.JobId)`                           | `${{ github.job }}`                                 |\n| `$(System.JobName)`                         | `${{ github.job }}`                                 |\n| `$(System.PullRequest.PullRequestId)`       | `${{ github.event.number }}`                        |\n| `$(System.PullRequest.PullRequestNumber)`   | `${{ github.event.number }}`                        |\n| `$(System.PullRequest.SourceBranch)`        | `${{ github.ref }}`                                 |\n| `$(System.PullRequest.SourceRepositoryUri)` | `${{ github.server.url }}/${{ github.repository }}` |\n| `$(System.PullRequest.TargetBranch)`        | `${{ github.event.base.ref }}`                      |\n| `$(System.PullRequest.TargetBranchName)`    | `${{ github.event.base.ref }}`                      |\n| `$(System.StageAttempt)`                    | `${{ github.run_number }}`                          |\n| `$(System.TeamFoundationCollectionUri)`     | `${{ github.server.url }}/${{ github.repository }}` |\n| `$(System.WorkFolder)`                      | `${{ github.workspace }}`                           |\n\n### Modelos\n\nVocê pode transformar modelos de Azure DevOps com GitHub Actions Importer.\n\n#### Limitações\n\nGitHub Actions Importeré capaz de transformar modelos Azure DevOps com algumas limitações.\n\n* Os modelos do Azure DevOps usados sob as chaves `stages`, `deployments` e `jobs` são convertidos em fluxos de trabalho reutilizáveis em GitHub Actions. Para saber mais, confira [Reutilizar fluxos de trabalho](/pt/actions/how-tos/reuse-automations/reuse-workflows).\n* Modelos do Azure DevOps usados na chave `steps` são convertidos em ações compostas. Para saber mais, confira [Criar uma ação composta](/pt/actions/tutorials/create-actions/create-a-composite-action).\n* Se você tiver atualmente modelos de trabalho que fazem referência a outros modelos de trabalho, GitHub Actions Importer converterá os modelos em fluxos de trabalho reutilizáveis. Como os fluxos de trabalho reutilizáveis não podem referenciar outros fluxos de trabalho reutilizáveis, essa sintaxe é inválida em GitHub Actions. Você precisa corrigir manualmente os fluxos de trabalho aninhados reutilizáveis.\n* Se um modelo fizer referência a uma organização ou GitHub repositório Azure DevOps externo, você deverá usar a opção `--credentials-file` para fornecer credenciais para acessar esse modelo. Para saber mais, confira [Argumentos e configurações complementares](/pt/actions/reference/github-actions-importer/supplemental-arguments-and-settings#using-a-credentials-file-for-authentication).\n* Você pode gerar o YAML dinamicamente usando expressões `each` com as seguintes advertências:\n  * Não há suporte para blocos `each` aninhados, e eles fazem com que o bloco pai `each` não tenha suporte.\n  * `each` e as condições `if` contidas são avaliadas durante a transformação, pois GitHub Actions não oferece suporte a esse estilo de inserção.\n  * Não há suporte para blocos `elseif`. Se essa funcionalidade for necessária, você precisará corrigi-las manualmente.\n  * Há suporte para blocos `if` aninhados, mas não há suporte para blocos `if/elseif/else` aninhados em uma condição `if`.\n  * não há suporte para blocos de `if` que usam variáveis de Azure DevOps predefinidas.\n\n#### Modelos com suporte\n\nGitHub Actions Importer dá suporte aos modelos listados na tabela abaixo.\n\n| Azure Pipelines                                                              | GitHub Actions                        |          Status |\n| :--------------------------------------------------------------------------- | :------------------------------------ | --------------: |\n| Estendendo a partir de um modelo                                             | `Reusable workflow`                   |     Com suporte |\n| Modelos de trabalho                                                          | `Reusable workflow`                   |     Com suporte |\n| Modelos de etapas                                                            | `Reusable workflow`                   |     Com suporte |\n| Modelos de etapa                                                             | `Composite action`                    |     Com suporte |\n| Grupos de tarefas no editor clássico                                         | Varia                                 |     Com suporte |\n| Modelos em uma organização, projeto ou repositório de Azure DevOps diferente | Varia                                 |     Com suporte |\n| Modelos em um repositório GitHub                                             | Varia                                 |     Com suporte |\n| Modelos de variável                                                          | `env`                                 |     Com suporte |\n| Inserção condicional                                                         | Condições `if` no trabalho/nas etapas | Suporte parcial |\n| Inserção iterativa                                                           | Não aplicável                         | Suporte parcial |\n| Modelos com parâmetros                                                       | Varia                                 | Suporte parcial |\n\n#### Nomes de caminho de arquivo de modelo\n\nGitHub Actions Importer pode extrair modelos com caminhos de arquivo relativos ou dinâmicos com variável, parâmetro e expressões iterativas no nome do arquivo. No entanto, é preciso haver um conjunto de valores padrão.\n\n##### Exemplo de nome de caminho de arquivo variável\n\n```yaml\n# File: azure-pipelines.yml\nvariables:\n- template: 'templates/vars.yml'\n\nsteps:\n- template: \"./templates/$\"\n```\n\n```yaml\n# File: templates/vars.yml\nvariables:\n  one: 'simple_step.yml'\n```\n\n##### Exemplo de nome do caminho de arquivo de parâmetro\n\n```yaml\nparameters:\n- name: template\n  type: string\n  default: simple_step.yml\n\nsteps:\n- template: \"./templates/${{ parameters.template }}\"\n```\n\n##### Exemplo de nome do caminho de arquivo iterativo\n\n```yaml\nparameters:\n- name: steps\n  type: object\n  default:\n  - build_step\n  - release_step\nsteps:\n- ${{ each step in parameters.steps }}:\n    - template: \"$-variables.yml\"\n```\n\n#### Parâmetros de modelo\n\nGitHub Actions Importer dá suporte aos parâmetros listados na tabela abaixo.\n\n| Azure Pipelines                            | GitHub Actions   | Status          |\n| :----------------------------------------- | :--------------- | :-------------- |\n| cadeia                                     | `inputs.string`  | Com suporte     |\n| número                                     | `inputs.number`  | Com suporte     |\n| booleano                                   | `inputs.boolean` | Com suporte     |\n| objeto                                     |                  |                 |\n| `inputs.string` com a expressão `fromJSON` | Suporte parcial  |                 |\n| etapa                                      | `step`           | Suporte parcial |\n| stepList                                   | `step`           | Suporte parcial |\n| cargo                                      | `job`            | Suporte parcial |\n| lista de trabalhos                         | `job`            | Suporte parcial |\n| implantação                                | `job`            | Suporte parcial |\n| deploymentList                             | `job`            | Suporte parcial |\n| fase                                       | `job`            | Suporte parcial |\n| listaDeEtapas                              | `job`            | Suporte parcial |\n\n> \\[!NOTE]\n> Um modelo usado na chave `step` com esse tipo de parâmetro só será serializado como uma ação composta se as etapas forem usadas no início ou no final das etapas do modelo. Um modelo usado nas chaves `stage`, `deployment` e `job` com esse tipo de parâmetro não é transformado em um fluxo de trabalho reutilizável e é serializado como um fluxo de trabalho independente.\n\n## Aviso legal\n\nPartes foram adaptadas do <https://github.com/github/gh-actions-importer/> de acordo com a licença MIT:\n\n```text\nMIT License\n\nCopyright (c) 2022 GitHub\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n```"}