{"meta":{"title":"Migrating from Azure DevOps with GitHub Actions Importer","intro":"Узнайте, как использовать GitHub Actions Importer для автоматизации миграции ваших Azure DevOps конвейеров в GitHub Actions.","product":"GitHub Actions","breadcrumbs":[{"href":"/ru/actions","title":"GitHub Actions"},{"href":"/ru/actions/tutorials","title":"Учебники"},{"href":"/ru/actions/tutorials/migrate-to-github-actions","title":"Миграция на GitHub Actions"},{"href":"/ru/actions/tutorials/migrate-to-github-actions/automated-migrations","title":"Автоматизированные миграции"},{"href":"/ru/actions/tutorials/migrate-to-github-actions/automated-migrations/azure-devops-migration","title":"Azure DevOps migration"}],"documentType":"article"},"body":"# Migrating from Azure DevOps with GitHub Actions Importer\n\nУзнайте, как использовать GitHub Actions Importer для автоматизации миграции ваших Azure DevOps конвейеров в GitHub Actions.\n\n## О миграции с Azure DevOps с помощью GitHub Actions Importer\n\nИнструкции ниже помогут вам настроить вашу среду так, чтобы использовать GitHub Actions Importer для миграции Azure DevOps конвейеров в GitHub Actions.\n\n### Необходимые компоненты\n\n* Аккаунт Azure DevOps или организация с проектами и пайплайнами, которые вы хотите конвертировать в рабочие процессы GitHub Actions.\n* Доступ к созданию Azure DevOps personal access token для вашего аккаунта или организации.\n* Среда, в которой можно запускать контейнеры на основе Linux и устанавливать необходимые средства.\n * Docker установлен [](https://docs.docker.com/get-docker/) и запущен.\n\n * [GitHub Интерфейс командной строки](https://cli.github.com) установлен.\n > \\[!NOTE]\n > Контейнер GitHub Actions Importer и ИНТЕРФЕЙС командной строки не должны быть установлены на том же сервере, что и платформа CI.\n\n### Ограничения\n\nСуществуют некоторые ограничения при миграции с Azure DevOps на GitHub Actions с GitHub Actions Importer:\n\n* GitHub Actions Importer требует версии 5.0 API Azure DevOps, доступной либо в Azure DevOps Services, либо Azure DevOps Server 2019 году. Старые версии Azure DevOps Server не совместимы.\n* Задачи, неявно добавленные в Azure DevOps конвейер, такие как проверка исходного кода, могут быть добавлены в аудит GitHub Actions Importer в виде имени GUID. Чтобы найти понятное имя задачи для GUID, можно использовать следующий URL-адрес: `https://dev.azure.com/:organization/_apis/distributedtask/tasks/:guid`\n\n#### Задачи вручную\n\nНекоторые Azure DevOps конструкции необходимо вручную мигрировать из конфигураций Azure DevOps в GitHub Actions. Например:\n\n* Секреты организации, репозитория и среды\n* Подключения службы, такие как OIDC Connect, GitHub Apps, и personal access tokens\n* Неизвестные задачи\n* Локальные агенты\n* Среды\n* Утверждения перед развертыванием\n\nДополнительные сведения о миграции вручную см. в разделе [Migrating from Azure Pipelines to GitHub Actions](/ru/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-azure-pipelines-to-github-actions).\n\n#### Неподдерживаемые задачи\n\nGitHub Actions Importer не поддерживает перенос следующих задач:\n\n* Шлюзы перед развертыванием\n* Шлюзы после развертывания\n* Утверждения после развертывания\n* Некоторые триггеры ресурсов\n\n## Установка расширения CLI GitHub Actions Importer\n\n1. Установите расширение CLI GitHub Actions Importer :\n\n ```bash copy\n gh extension install github/gh-actions-importer\n ```\n\n2. Убедитесь, что расширение установлено:\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## Настройка учетных данных\n\nКоманда `configure` CLI используется для установки необходимых учетных данных и опций для GitHub Actions Importer при работе с Azure DevOps и GitHub.\n\n1. Создайте GitHub personal access token (classic). Дополнительные сведения см. в разделе [Управление личными маркерами доступа](/ru/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic).\n\n У маркера `workflow` должна быть область.\n\n После создания маркера скопируйте его и сохраните его в безопасном расположении для последующего использования.\n\n2. Создать Azure DevOps personal access token. Для получения дополнительной информации см. [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) в документации Azure DevOps. Маркер должен иметь следующие области:\n\n * Пул агентов: `Read`\n * Сборка: `Read`\n * Код: `Read`\n * Релиз: `Read`\n * Подключения к службе: `Read`\n * Группы задач: `Read`\n * Группы переменных: `Read`\n\n После создания маркера скопируйте его и сохраните его в безопасном расположении для последующего использования.\n\n3. В терминале выполните команду CLI GitHub Actions Importer `configure` :\n\n ```shell\n gh actions-importer configure\n ```\n\n В командной строке появится следующая `configure` информация:\n\n * Для вопроса «Каких провайдеров CI вы настраиваете?» используйте стрелки, чтобы выбрать `Azure DevOps`, нажмите Space чтобы выбрать его, затем нажмите Enter.\n * Для «Personal access token for GitHub введите значение personal access token (classic), которое вы создали ранее, и нажмите Enter.\n * Для «Базового URL GitHub экземпляра» нажмите Enter чтобы принять значение по умолчанию (`https://github.com`).\n * Для «Personal access token for Azure DevOps введите значение Azure DevOps personal access token, которое вы создали ранее, и нажмите Enter.\n * Для «Базовый URL Azure DevOps экземпляра» нажмите Enter, чтобы принять значение по умолчанию (`https://dev.azure.com`).\n * Для «Azure DevOps название организации» введите название вашей Azure DevOps организации и нажмите Enter.\n * Для «Azure DevOps названия проекта» введите название вашего Azure DevOps проекта и нажмите Enter.\n\n Ниже показан пример `configure` команды:\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. В терминале выполните команду CLI GitHub Actions Importer `update` для подключения к GitHub Packages Container registry и убедитесь, что образ контейнера обновлен до последней версии:\n\n ```shell\n gh actions-importer update\n ```\n\n Выходные данные команды должны выглядеть следующим образом:\n\n ```shell\n Updating ghcr.io/actions-importer/cli:latest...\n ghcr.io/actions-importer/cli:latest up-to-date\n ```\n\n## Perform an audit of Azure DevOps\n\nВы можете использовать команду `audit`, чтобы получить общий обзор всех проектов в Azure DevOps организации.\n\nКоманда `audit` выполняет следующие действия.\n\n1. Fetches all projects, defined in a Azure DevOps organization.\n2. Преобразует каждый конвейер в эквивалентный рабочий процесс GitHub Actions .\n3. Создает отчет, в котором приводится сводка о том, как полная и сложная миграция возможна с помощью GitHub Actions Importer.\n\n### Выполнение команды аудита\n\nДля проведения аудита организации Azure DevOps выполните следующую команду в вашем терминале:\n\n```shell\ngh actions-importer audit azure-devops --output-dir tmp/audit\n```\n\n### Проверка результатов аудита\n\nФайлы в указанном выходном каталоге содержат результаты аудита. `audit_summary.md` Ознакомьтесь с файлом с сводкой результатов аудита.\n\nСводка аудита содержит следующие разделы.\n\n#### Pipelines\n\nРаздел \"Конвейеры\" содержит высокоуровневую статистику относительно скорости преобразования, выполняемой GitHub Actions Importer.\n\nНиже перечислены некоторые ключевые термины, которые могут отображаться в разделе \"Конвейеры\":\n\n* **Успешные** конвейеры имели 100 % конструкций конвейера и отдельные элементы, преобразованные автоматически в их эквивалент GitHub Actions.\n* **Частично успешные** конвейеры были преобразованы все конструкции конвейера, однако существовали некоторые отдельные элементы, которые не были автоматически преобразованы в их эквивалент GitHub Actions.\n* **Неподдерживаемые** конвейеры — это типы определений, которые не поддерживаются GitHub Actions Importer.\n* **Неудачные** конвейеры столкнулись с неустранимой ошибкой при преобразовании. Это может произойти по одной из трех причин:\n * Конвейер изначально был неправильно настроен и недопустим.\n * При преобразовании данных GitHub Actions Importer возникла внутренняя ошибка.\n * Произошел неудачный сетевой ответ, который привел к недоступности конвейера, что часто связано с недопустимыми учетными данными.\n\n#### Этапы сборки\n\nВ разделе \"Шаги сборки\" содержится обзор отдельных шагов сборки, используемых во всех конвейерах, и количество автоматически преобразованных GitHub Actions Importer.\n\nНиже приведены некоторые ключевые термины, которые могут отображаться в разделе \"Шаги сборки\".\n\n* Известный \\*\\*\\*\\* шаг сборки — это шаг, который был автоматически преобразован в эквивалентное действие.\n* \\*\\* Неизвестный \\*\\*шаг сборки — это шаг, который не был автоматически преобразован в эквивалентное действие.\n* Неподдерживаемый \\*\\*\\*\\* шаг сборки — это шаг, который является следующим:\n * В основном не поддерживается GitHub Actions.\n * Настроено таким образом, что несовместимо с данными GitHub Actions.\n* Действие \\*\\*\\*\\* — это список действий, которые использовались в преобразованных рабочих процессах. Это может быть важно для:\n * Если вы используете GitHub Enterprise Server, собирайте список действий для синхронизации с экземпляром.\n * Определение списка разрешений на уровне организации используемых действий. Этот список действий — это полный список действий, которые могут потребоваться для проверки вашей группы безопасности или соответствия требованиям.\n\n#### Задачи вручную\n\nВ разделе \"Задачи вручную\" содержится обзор задач, которые GitHub Actions Importer не могут выполняться автоматически, и что необходимо выполнить вручную.\n\nНиже перечислены некоторые ключевые термины, которые могут отображаться в разделе \"Задачи вручную\".\n\n* Секрет **— это репозиторий или секрет** уровня организации, используемый в преобразованных конвейерах. Эти секреты необходимо создать вручную в GitHub Actions для правильной работы этих конвейеров. Дополнительные сведения см. в разделе [Использование секретов в GitHub Actions](/ru/actions/security-guides/using-secrets-in-github-actions).\n* Локальное **средство** выполнения ссылается на метку бегуна, на который ссылается преобразованный конвейер, который не является GitHub, размещенным в runner. Необходимо вручную определить эти средства выполнения для правильной работы этих конвейеров.\n\n#### Файлы\n\nПоследний раздел отчета аудита содержит манифест всех файлов, записанных на диск во время аудита.\n\nКаждый файл конвейера содержит различные файлы, включенные в аудит, в том числе:\n\n* Исходный конвейер, определенный в GitHub.\n* Все сетевые ответы, используемые для преобразования конвейера.\n* Преобразованный файл рабочего процесса.\n* Трассировки стека, которые можно использовать для устранения неполадок с неудачным преобразованием конвейера.\n\nКроме того, `workflow_usage.csv` файл содержит разделенный запятыми список всех действий, секретов и средств выполнения, используемых каждым успешно преобразованным конвейером. Это может быть полезно для определения рабочих процессов, которые используют действия, секреты или средства выполнения, и могут быть полезны для выполнения проверок безопасности.\n\n## Прогнозирование потенциального использования данных GitHub Actions\n\nВы можете использовать команду `forecast` для прогнозирования потенциального использования GitHub Actions, вычисляя метрики из завершённых запусков конвейера в Azure DevOps.\n\n### Выполнение команды прогноза\n\nЧтобы выполнить прогноз потенциального использования данных GitHub Actions, выполните следующую команду в терминале. По умолчанию GitHub Actions Importer включает предыдущие семь дней в отчете прогноза.\n\n```shell\ngh actions-importer forecast azure-devops --output-dir tmp/forecast_reports\n```\n\n### Проверка отчета прогноза\n\nФайл `forecast_report.md` в указанном выходном каталоге содержит результаты прогноза.\n\nНиже перечислены некоторые ключевые термины, которые могут отображаться в отчете прогноза:\n\n* Число **заданий** — общее количество завершенных заданий.\n* Число **конвейеров — это количество уникальных используемых конвейеров** .\n* **Время** выполнения описывает время выполнения, затраченное на задание. Эту метрику можно использовать для планирования стоимости GitHubразмещенных средств выполнения.\n\n Эта метрика сопоставляется с тем, сколько следует потратить в GitHub Actions. Это зависит от оборудования, используемого в эти минуты. Вы можете использовать [калькулятор](https://github.com/pricing/calculator) цен GitHub Actions для оценки затрат.\n* **Метрики времени** очереди описывают время, затраченное на выполнение задания, ожидающего доступности средства выполнения.\n* **Метрики параллельных заданий** описывают количество заданий, выполняемых в любое время. Эту метрику можно использовать для определения количества модулей выполнения, которые необходимо настроить.\n\nКроме того, эти метрики определяются для каждой очереди бегущих в Azure DevOps. Это особенно полезно, если имеется сочетание размещенных или локальных runners, или компьютеров с высокой или низкой спецификацией, поэтому вы можете видеть метрики, относящиеся к различным типам runners.\n\n## Выполнение пробной миграции\n\nВы можете использовать команду `dry-run`, чтобы преобразовать Azure DevOps конвейер в эквивалентный GitHub Actions рабочий процесс. Сухой запуск создает выходные файлы в указанном каталоге, но не открывает запрос на вытягивание для переноса конвейера.\n\nЕсли есть что-либо, что GitHub Actions Importer не удалось преобразовать автоматически, например неизвестные шаги сборки или частично успешный конвейер, может потребоваться создать пользовательские преобразователи для дальнейшей настройки процесса преобразования. Дополнительные сведения см. в разделе [Расширение импортера GitHub Actions с пользовательскими трансформерами](/ru/actions/migrating-to-github-actions/automated-migrations/extending-github-actions-importer-with-custom-transformers).\n\n### Выполнение команды dry-run для конвейера сборки\n\nЧтобы выполнить пробный запуск миграции конвейера Azure DevOps build в GitHub Actions, выполните следующую команду в терминале, заменив `pipeline_id` на ID конвейера, который вы конвертируете.\n\n```shell\ngh actions-importer dry-run azure-devops pipeline --pipeline-id :pipeline_id --output-dir tmp/dry-run\n```\n\nЖурналы сухого запуска и преобразованных файлов рабочих процессов можно просмотреть в указанном выходном каталоге.\n\n### Выполнение команды dry-run для конвейера выпуска\n\nЧтобы провести пробный запуск миграции конвейера Azure DevOps release в GitHub Actions, выполните следующую команду в терминале, заменив `pipeline_id` на идентификатор конвейера, который вы конвертируете.\n\n```shell\ngh actions-importer dry-run azure-devops release --pipeline-id :pipeline_id --output-dir tmp/dry-run\n```\n\nЖурналы сухого запуска и преобразованных файлов рабочих процессов можно просмотреть в указанном выходном каталоге.\n\n## Выполнение рабочей миграции\n\nВы можете использовать команду `migrate`, чтобы преобразовать Azure DevOps конвейер и открыть pull request с эквивалентным рабочим процессом GitHub Actions.\n\n### Выполнение команды миграции для конвейера сборки\n\nЧтобы мигрировать конвейер Azure DevOps build в GitHub Actions, выполните следующую команду в вашем терминале, заменив значение `target-url` на URL вашего репозитория GitHub и `pipeline_id` на идентификатор конвертируемого конвейера.\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\nВыходные данные команды включают URL-адрес запроса на вытягивание, который добавляет преобразованный рабочий процесс в репозиторий. Пример успешного вывода аналогичен следующему:\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### Выполнение команды миграции для конвейера выпуска\n\nЧтобы мигрировать конвейер релизов Azure DevOps в GitHub Actions, выполните следующую команду в терминале, заменив значение `target-url` на URL репозитория GitHub и `pipeline_id` идентификатором конверсионного конвейера.\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\nВыходные данные команды включают URL-адрес запроса на вытягивание, который добавляет преобразованный рабочий процесс в репозиторий. Пример успешного вывода аналогичен следующему:\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### Проверка запроса на вытягивание\n\nВыходные данные из успешного `migrate` выполнения команды содержат ссылку на новый запрос на вытягивание, который добавляет преобразованный рабочий процесс в репозиторий.\n\nНиже приведены некоторые важные элементы запроса на вытягивание:\n\n* В описании запроса на вытягивание раздел с именем **\"Вручную\", в котором перечислены шаги**, которые необходимо выполнить вручную, прежде чем завершить перенос конвейеров на GitHub Actions. Например, в этом разделе может быть описано создание секретов, используемых в рабочих процессах.\n* Преобразованный файл рабочих процессов. Выберите вкладку \"\\*\\*Измененные файлы\" в запросе \\*\\*на вытягивание, чтобы просмотреть файл рабочего процесса, который будет добавлен в репозиторий GitHub .\n\nПосле завершения проверки запроса на вытягивание его можно объединить, чтобы добавить рабочий процесс в репозиторий GitHub .\n\n## Справочные материалы\n\nВ этом разделе содержится справочная информация о переменных окружения, необязательных аргументах и поддерживаемом синтаксисе при использовании GitHub Actions Importer для миграции из Azure DevOps.\n\n### Переменные среды конфигурации\n\nGitHub Actions Importer использует переменные среды для конфигурации проверки подлинности. Эти переменные задаются при выполнении процесса конфигурации с помощью `configure` команды. Дополнительные сведения см. в [разделе \"Настройка учетных](#configuring-credentials) данных\".\n\nGitHub Actions Importer использует следующие переменные среды для подключения к вашему Azure DevOps экземпляру:\n\n* `GITHUB_ACCESS_TOKEN`: personal access token (classic) используется для создания запросов на вытягивание с преобразованным рабочим процессом (требуется `workflow` область).\n* `GITHUB_INSTANCE_URL`: URL-адрес целевого экземпляра GitHub (например, `https://github.com`).\n* `AZURE_DEVOPS_ACCESS_TOKEN`: Данные personal access token использовались для аутентификации с вашим Azure DevOps экземпляром. Для этого маркера требуются следующие области:\n * Сборка: `Read`\n * Пулы агентов: `Read`\n * Код: `Read`\n * Релиз: `Read`\n * Подключения к службе: `Read`\n * Группы задач: `Read`\n * Группы переменных: `Read`\n* `AZURE_DEVOPS_PROJECT`: имя проекта или GUID, используемые при переносе конвейера. Если вы хотите выполнить аудит для всех проектов, это необязательно.\n* `AZURE_DEVOPS_ORGANIZATION`: Название организации вашего Azure DevOps инстанса.\n* `AZURE_DEVOPS_INSTANCE_URL`: URL Azure DevOps экземпляра, например `https://dev.azure.com`.\n\nЭти переменные среды можно указать в `.env.local` файле, загруженном GitHub Actions Importer при запуске.\n\n### Необязательные аргументы\n\nСуществуют необязательные аргументы, которые можно использовать с подкомандами GitHub Actions Importer для настройки миграции.\n\n#### `--source-file-path`\n\nАргумент можно использовать `--source-file-path` с `forecast``dry-run`подкомандами или `migrate` подкомандами.\n\nПо умолчанию GitHub Actions Importer извлекает содержимое конвейера из системы управления версиями. Аргумент `--source-file-path` указывает GitHub Actions Importer использовать указанный путь к исходному файлу.\n\nНапример:\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\nАргумент можно использовать `--config-file-path` с `audit``dry-run`подкомандами и `migrate` подкомандами.\n\nПо умолчанию GitHub Actions Importer извлекает содержимое конвейера из системы управления версиями. Аргумент `--config-file-path` указывает GitHub Actions Importer использовать указанные исходные файлы.\n\nАргумент `--config-file-path` также можно использовать для указания репозитория преобразованного повторно используемого рабочего процесса или составного действия.\n\n##### Пример аудита\n\nВ этом примере GitHub Actions Importer использует указанный файл конфигурации YAML в качестве исходного файла для выполнения аудита.\n\n```shell\ngh actions-importer audit azure-devops pipeline --output-dir ./output/ --config-file-path ./path/to/azure_devops/config.yml\n```\n\nДля аудита Azure DevOps экземпляра с использованием конфигурационного файла конфигурационный файл должен быть в следующем формате, и каждый `repository_slug` должен быть уникальным:\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\nВы можете сгенерировать `repository_slug` для конвейера, объединив имя организации Azure DevOps, проекта и идентификатор конвейера. Например: `my-organization-name/my-project-name/42`.\n\n##### Пример сухого запуска\n\nВ этом примере GitHub Actions Importer использует указанный файл конфигурации YAML в качестве исходного файла для выполнения сухого запуска.\n\nКонвейер выбирается путем сопоставления `repository_slug` в файле конфигурации со значением и `--azure-devops-organization` параметром`--azure-devops-project`. Затем `path` используется для извлечения указанного исходного файла.\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##### Указание репозитория преобразованных повторно используемых рабочих процессов и составных действий\n\nGitHub Actions Importer использует файл YAML, `--config-file-path` предоставленный аргументу, для определения репозитория, в который переносятся преобразованные повторно используемые рабочие процессы и составные действия.\n\nЧтобы начать, необходимо выполнить аудит без аргумента `--config-file-path` :\n\n```shell\ngh actions-importer audit azure-devops --output-dir ./output/\n```\n\nВыходные данные этой команды содержат файл с именем `config.yml` , содержащий список всех повторно используемых рабочих процессов и составных действий, преобразованных GitHub Actions Importer. Например, `config.yml` файл может содержать следующее содержимое:\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\nЭтот файл можно использовать для указания репозитория и ссылки на повторно используемый рабочий процесс или составное действие. Затем можно использовать `--config-file-path` аргумент для предоставления `config.yml` файла GitHub Actions Importer. Например, этот файл можно использовать при выполнении `migrate` команды, чтобы открыть запрос на вытягивание для каждого уникального репозитория, определенного в файле конфигурации:\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### Поддерживаемый синтаксис для Azure DevOps pipelines\n\nВ следующей таблице показан тип свойств, которые GitHub Actions Importer в настоящее время могут преобразовывать.\n\n| Azure Pipelines | GitHub Actions | Состояние |\n| :--------------------- | :----------------------------------------------------------------------------------------------------------------------------------------- | :---------------------- |\n| condition | | Поддерживается |\n| контейнер | | Поддерживается |\n| непрерывнаяintegration | | Поддерживается |\n| задание | | Поддерживается |\n| pullRequest | | Поддерживается |\n| постановка | | Поддерживается |\n| steps | | Поддерживается |\n| бизнеса | | Поддерживается |\n| timeoutInMinutes | | Поддерживается |\n| переменные | | Поддерживается |\n| развертывание вручную | | Частично поддерживается |\n| pool | | Частично поддерживается |\n| services; | | Частично поддерживается |\n| бизнеса | | Частично поддерживается |\n| триггеры | | Частично поддерживается |\n| pullRequest | | Не поддерживается |\n| schedules | | Не поддерживается |\n| триггеры | | Не поддерживается |\n\nДля получения дополнительной информации о поддерживаемых Azure DevOps задачах см. репозиторий [`github/gh-actions-importer`](https://github.com/github/gh-actions-importer/blob/main/docs/azure_devops/index.md).\n\n### Сопоставление переменных среды\n\nGitHub Actions Importer использует отображение из таблицы ниже для преобразования переменных по умолчанию Azure DevOps среды в ближайший эквивалент в 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### Шаблоны\n\nВы можете преобразовать Azure DevOps шаблоны с помощью GitHub Actions Importer.\n\n#### Ограничения\n\nGitHub Actions Importer способен преобразовывать Azure DevOps шаблоны с некоторыми ограничениями.\n\n* Azure DevOps шаблоны, используемые под клавишами `stages`, `deployments` и `jobs`, преобразуются в повторно используемые рабочие процессы в GitHub Actions. Дополнительные сведения см. в разделе [Повторное использование рабочих процессов](/ru/actions/using-workflows/reusing-workflows).\n* Azure DevOps шаблоны, используемые под ключом `steps`, преобразуются в составные действия. Дополнительные сведения см. в разделе [Создание составного действия](/ru/actions/creating-actions/creating-a-composite-action).\n* Если у вас есть шаблоны заданий, ссылающиеся на другие шаблоны заданий, GitHub Actions Importer преобразует шаблоны в повторно используемые рабочие процессы. Так как повторно используемые рабочие процессы не могут ссылаться на другие повторно используемые рабочие процессы, это недопустимый синтаксис в GitHub Actions. Необходимо вручную исправить вложенные повторно используемые рабочие процессы.\n* Если шаблон ссылается на внешнюю организацию Azure DevOps или репозиторий GitHub, необходимо использовать опцию `--credentials-file` для предоставления учетных данных для доступа к этому шаблону. Дополнительные сведения см. в разделе [Дополнительные аргументы и параметры](/ru/actions/migrating-to-github-actions/automated-migrations/supplemental-arguments-and-settings#using-a-credentials-file-for-authentication).\n* Вы можете динамически создавать YAML с помощью `each` выражений с помощью следующих предостережения:\n * Вложенные `each` блоки не поддерживаются и вызывают неподдерживаемый родительский `each` блок.\n * `each` и содержащиеся `if` условия оцениваются во время преобразования, так как GitHub Actions не поддерживает этот стиль вставки.\n * `elseif` блоки не поддерживаются. Если эта функция необходима, их необходимо исправить вручную.\n * Вложенные `if` блоки поддерживаются, но `if/elseif/else` блоки, вложенные в `if` условие, не поддерживаются.\n * Блоки `if`, использующие предопределённые переменные Azure DevOps, не поддерживаются.\n\n#### Поддерживаемые шаблоны\n\nGitHub Actions Importer поддерживает шаблоны, перечисленные в таблице ниже.\n\n| Azure Pipelines | GitHub Actions | Состояние |\n| :------------------------------------------------------------------------ | :------------------ | -------------: |\n| Расширение из шаблона | `Reusable workflow` | Поддерживается |\n| Шаблоны задания | `Reusable workflow` | Поддерживается |\n| Шаблоны этапов | `Reusable workflow` | Поддерживается |\n| Шаблоны шагов | `Composite action` | Поддерживается |\n| Группы задач в классическом редакторе | Разные | Поддерживается |\n| Templates in a different Azure DevOps organization, project or repository | Разные | Поддерживается |\n| Шаблоны в репозитории GitHub | Разные | Поддерживается |\n| Шаблоны переменных | `env` | Поддерживается |\n| Условное вставка | | |\n\n```\n `if` условия задания и действия | Частично поддерживается |\n```\n\n\\| Итеративная вставка | Нет данных | Частично поддерживается |\n\\| Шаблоны с параметрами | Разные | Частично поддерживается |\n\n#### Имена путей к файлу шаблона\n\nGitHub Actions Importer может извлекать шаблоны с относительными или динамическими путями к файлам с переменными, параметрами и итеративными выражениями в имени файла. Однако должно быть задано значение по умолчанию.\n\n##### Пример имени пути к файлу переменной\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##### Пример имени пути к файлу параметров\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##### Пример имени пути к итеративному файлу\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#### Параметры шаблона\n\nGitHub Actions Importer поддерживает параметры, перечисленные в таблице ниже.\n\n| Azure Pipelines | GitHub Actions | Состояние |\n| :-------------- | :--------------- | :------------- |\n| строка | `inputs.string` | Поддерживается |\n| number | `inputs.number` | Поддерживается |\n| boolean | `inputs.boolean` | Поддерживается |\n| объект | | |\n\n```\n `inputs.string`с выражением `fromJSON` | Частично поддерживается |\n```\n\n\\| step | `step` | Частично поддерживается |\n\\| stepList | `step` | Частично поддерживается |\n\\| задание | `job` | Частично поддерживается |\n\\| jobList | `job` | Частично поддерживается |\n\\| развертывание | `job` | Частично поддерживается |\n\\| deploymentList | `job` | Частично поддерживается |\n\\| постановка | `job` | Частично поддерживается |\n\\| stageList | `job` | Частично поддерживается |\n\n> \\[!NOTE]\n> Шаблон, используемый под ключом `step` с этим типом параметров, сериализуется только в виде составного действия, если шаги используются в начале или конце шагов шаблона. Шаблон, используемый в разделе `stage`, `deployment`и `job` ключи с этим типом параметров не преобразуются в повторно используемый рабочий процесс, а вместо этого сериализуются как автономный рабочий процесс.\n\n## Юридическая информация\n\nЧасти были адаптированы в соответствии с лицензией 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```"}