Переход с Azure DevOps с помощью средства импорта GitHub Actions

Узнайте, как GitHub Actions Importer автоматизировать миграцию конвейеров GitHub ActionsAzure DevOps в .

В этой статье

О миграции с Azure DevOps с помощью GitHub Actions Importer

Приведенные ниже инструкции помогут вам настроить среду для GitHub Actions Importer переноса конвейеров GitHub ActionsAzure DevOps в .

Необходимые компоненты

  • Учетная запись или организация Azure DevOps с проектами и конвейерами, которые необходимо преобразовать в GitHub Actions рабочие процессы.
  • Доступ к созданию Azure DevOps personal access token для учетной записи или организации.
  • Среда, в которой можно запускать контейнеры на основе Linux и устанавливать необходимые средства.

    Примечание.

    Контейнер GitHub Actions Importer и ИНТЕРФЕЙС командной строки не должны быть установлены на том же сервере, что и платформа CI.

Ограничения

Существуют некоторые ограничения при миграции с Azure DevOps на GitHub ActionsGitHub Actions Importerследующие:

  • GitHub Actions Importerтребует версии 5.0 API Azure DevOps, доступной в службах Azure DevOps или Azure DevOps Server 2019. Старые версии Azure DevOps Server не совместимы.
  • Задачи, которые неявно добавляются в конвейер Azure DevOps, например извлечение исходного кода, могут быть добавлены в GitHub Actions Importer аудит в качестве имени GUID. Чтобы найти понятное имя задачи для GUID, можно использовать следующий URL-адрес: https://dev.azure.com/:organization/_apis/distributedtask/tasks/:guid

Задачи вручную

Некоторые Azure DevOps конструкции должны переноситься вручную из Azure DevOps в GitHub Actions конфигурации. Например:

  • Секреты организации, репозитория и среды
  • Подключения служб, такие как OIDC Connect, GitHub Appsи personal access tokens
  • Неизвестные задачи
  • Локальные агенты
  • Среды
  • Утверждения перед развертыванием

Дополнительные сведения о миграции вручную см. в разделе Переход с Azure Pipelines на GitHub Actions.

Неподдерживаемые задачи

GitHub Actions Importer не поддерживает миграцию следующих задач:

  • Шлюзы перед развертыванием
  • Шлюзы после развертывания
  • Утверждения после развертывания
  • Некоторые триггеры ресурсов

Установка GitHub Actions Importer расширения CLI

  1. Установите расширение CLI GitHub Actions Importer :

    Bash
    gh extension install github/gh-actions-importer

  2. Убедитесь, что расширение установлено:

    $ 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.

Настройка учетных данных

Команда configure CLI используется для задания необходимых учетных данных и параметров GitHub Actions Importer при работе с Azure DevOps и GitHub.

  1. Создайте GitHubpersonal access token (classic). Дополнительные сведения см. в разделе Управление личными маркерами доступа.

    У маркера workflow должна быть область.

    После создания маркера скопируйте его и сохраните его в безопасном расположении для последующего использования.

  2. Создание Azure DevOpspersonal access token. Дополнительные сведения смpersonal access tokens. в документации по Azure DevOps. Маркер должен иметь следующие области:

    • Пул агентов: Read
    • Сборка: Read
    • Код: Read
    • Релиз: Read
    • Подключения к службе: Read
    • Группы задач: Read
    • Группы переменных: Read

    После создания маркера скопируйте его и сохраните его в безопасном расположении для последующего использования.

  3. В терминале выполните GitHub Actions Importerconfigure команду CLI:

    gh actions-importer configure

    В командной строке появится следующая configure информация:

    • Для вопроса «Каких провайдеров CI вы настраиваете?» используйте стрелки, чтобы выбрать Azure DevOps, нажмите Space чтобы выбрать его, затем нажмите Enter.
    • Для "Personal access token for GitHub" введите значение того, personal access token (classic) что вы создали ранее, и нажмите Enter.
    • Для «Базового URL экземпляра GitHub» нажмите Enter , чтобы принять значение по умолчанию (https://github.com).
    • В поле "Personal access tokenдля Azure DevOps" введите значение для Azure DevOpspersonal access token, созданной ранее, и нажмите клавишу ВВОД.
    • Для «Базовый URL Azure DevOps экземпляра» нажмите Enter, чтобы принять значение по умолчанию (https://dev.azure.com).
    • Для «Azure DevOps название организации» введите название вашей Azure DevOps организации и нажмите Enter.
    • Для «Azure DevOps названия проекта» введите название вашего Azure DevOps проекта и нажмите Enter.

    Ниже показан пример configure команды:

    $ gh actions-importer configure
✔ Which CI providers are you configuring?: Azure DevOps
Enter the following values (leave empty to omit):
✔ Personal access token for GitHub: ***************
✔ Base url of the GitHub instance: https://github.com
✔ Personal access token for Azure DevOps: ***************
✔ Base url of the Azure DevOps instance: https://dev.azure.com
✔ Azure DevOps organization name: :organization
✔ Azure DevOps project name: :project
Environment variables successfully updated.

  4. В терминале GitHub Actions Importerupdate выполните команду CLI, чтобы подключиться к ней GitHub PackagesContainer registry и убедиться, что образ контейнера обновлен до последней версии:

    gh actions-importer update

    Выходные данные команды должны выглядеть следующим образом:

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

Выполнение аудита Azure DevOps

Вы можете использовать команду audit, чтобы получить общий обзор всех проектов в Azure DevOps организации.

Команда audit выполняет следующие действия.

  1. Fetches all projects, defined in a Azure DevOps organization.
  2. Преобразует каждый конвейер в его эквивалентный GitHub Actions рабочий процесс.
  3. Создаёт отчёт, в котором обобщается, насколько полной и сложной может быть миграция с .GitHub Actions Importer

Выполнение команды аудита

Для проведения аудита организации Azure DevOps выполните следующую команду в вашем терминале:

gh actions-importer audit azure-devops --output-dir tmp/audit

Проверка результатов аудита

Файлы в указанном выходном каталоге содержат результаты аудита. audit_summary.md Ознакомьтесь с файлом с сводкой результатов аудита.

Сводка аудита содержит следующие разделы.

Pipelines

Раздел "Конвейеры" содержит высокоуровневую статистику относительно скорости преобразования, выполняемой с помощью GitHub Actions Importer.

Ниже перечислены некоторые ключевые термины, которые могут отображаться в разделе "Конвейеры":

  • Успешные конвейеры имели 100% конструкций конвейера и отдельных элементов, преобразованных автоматически в их GitHub Actions эквивалент.
  • Частично успешные конвейеры были преобразованы все конструкции конвейера, однако были некоторые отдельные элементы, которые не были преобразованы автоматически в их GitHub Actions эквивалент.
  • Неподдерживаемые конвейеры — это типы определений, которые не поддерживаются GitHub Actions Importer.
  • Неудачные конвейеры столкнулись с неустранимой ошибкой при преобразовании. Это может произойти по одной из трех причин:
    • Конвейер изначально был неправильно настроен и недопустим.
    • GitHub Actions Importer при преобразовании произошла внутренняя ошибка.
    • Произошел неудачный сетевой ответ, который привел к недоступности конвейера, что часто связано с недопустимыми учетными данными.

Этапы сборки

В разделе "Шаги сборки" содержится обзор отдельных шагов сборки, используемых во всех конвейерах, и количество автоматически преобразованных GitHub Actions Importer.

Ниже приведены некоторые ключевые термины, которые могут отображаться в разделе "Шаги сборки".

  • Известный **** шаг сборки — это шаг, который был автоматически преобразован в эквивалентное действие.
  • ** Неизвестный **шаг сборки — это шаг, который не был автоматически преобразован в эквивалентное действие.
  • Неподдерживаемый **** шаг сборки — это шаг, который является следующим:
    • Принципиально не поддерживается GitHub Actions.
    • Настроено таким образом, что несовместимо с GitHub Actions.
  • Действие **** — это список действий, которые использовались в преобразованных рабочих процессах. Это может быть важно для:
    • При использовании GitHub Enterprise Serverсобирайте список действий для синхронизации с экземпляром.
    • Определение списка разрешений на уровне организации используемых действий. Этот список действий — это полный список действий, которые могут потребоваться для проверки вашей группы безопасности или соответствия требованиям.

Задачи вручную

В разделе "Задачи вручную" содержится обзор задач, которые GitHub Actions Importer не могут выполняться автоматически, и необходимо выполнить вручную.

Ниже перечислены некоторые ключевые термины, которые могут отображаться в разделе "Задачи вручную".

  • Секрет — это репозиторий или секрет уровня организации, используемый в преобразованных конвейерах. Эти секреты необходимо создать вручную GitHub Actions для правильной работы этих конвейеров. Дополнительные сведения см. в разделе Использование секретов в GitHub Actions.
  • Локальное средство выполнения ссылается на метку бегуна, на который ссылается преобразованный конвейер, который не является размещенным GitHubrunner. Необходимо вручную определить эти средства выполнения для правильной работы этих конвейеров.

Файлы

Последний раздел отчета аудита содержит манифест всех файлов, записанных на диск во время аудита.

Каждый файл конвейера содержит различные файлы, включенные в аудит, в том числе:

  • Исходный конвейер, определенный в GitHub.
  • Все сетевые ответы, используемые для преобразования конвейера.
  • Преобразованный файл рабочего процесса.
  • Трассировки стека, которые можно использовать для устранения неполадок с неудачным преобразованием конвейера.

Кроме того, workflow_usage.csv файл содержит разделенный запятыми список всех действий, секретов и средств выполнения, используемых каждым успешно преобразованным конвейером. Это может быть полезно для определения рабочих процессов, которые используют действия, секреты или средства выполнения, и могут быть полезны для выполнения проверок безопасности.

Прогноз потенциального GitHub Actions использования

С помощью forecast команды можно прогнозировать потенциальное GitHub Actions использование, вычисляя метрики из завершенного конвейера в Azure DevOps.

Выполнение команды прогноза

Чтобы выполнить прогноз возможного GitHub Actions использования, выполните следующую команду в вашем терминале. По умолчанию GitHub Actions Importer включает предыдущие семь дней в прогнозный отчёт.

gh actions-importer forecast azure-devops --output-dir tmp/forecast_reports

Проверка отчета прогноза

Файл forecast_report.md в указанном выходном каталоге содержит результаты прогноза.

Ниже перечислены некоторые ключевые термины, которые могут отображаться в отчете прогноза:

  • Число заданий — общее количество завершенных заданий.

  • Число конвейеров — это количество уникальных используемых конвейеров .

  • Время выполнения описывает время выполнения, затраченное на задание. Этот показатель помогает планировать стоимость GitHub-hosted runners.

    Этот показатель коррелирует с тем, сколько вы должны ожидать в GitHub Actions. Это зависит от оборудования, используемого в эти минуты. Вы можете использовать GitHub Actions калькулятор ценообразования , чтобы оценить затраты.

  • Метрики времени очереди описывают время, затраченное на выполнение задания, ожидающего доступности средства выполнения.

  • Метрики параллельных заданий описывают количество заданий, выполняемых в любое время. Эту метрику можно использовать для определения количества модулей выполнения, которые необходимо настроить.

Кроме того, эти метрики определяются для каждой очереди бегущих в Azure DevOps. Это особенно полезно, если имеется сочетание размещенных или локальных runners, или компьютеров с высокой или низкой спецификацией, поэтому вы можете видеть метрики, относящиеся к различным типам runners.

Выполнение пробной миграции

С помощью dry-run команды можно преобразовать конвейер Azure DevOps в эквивалентный GitHub Actions рабочий процесс. Сухой запуск создает выходные файлы в указанном каталоге, но не открывает запрос на вытягивание для переноса конвейера.

Если есть что-либо, что GitHub Actions Importer не удалось преобразовать автоматически, например неизвестные шаги сборки или частично успешный конвейер, может потребоваться создать пользовательские преобразователи для дальнейшей настройки процесса преобразования. Дополнительные сведения см. в разделе Расширение импортера GitHub Actions с пользовательскими трансформерами.

Выполнение команды dry-run для конвейера сборки

Чтобы выполнить сухой запуск миграции конвейера GitHub Actionsсборки Azure DevOps, выполните следующую команду в терминале, заменив pipeline_id идентификатор преобразованного конвейера.

gh actions-importer dry-run azure-devops pipeline --pipeline-id :pipeline_id --output-dir tmp/dry-run

Журналы сухого запуска и преобразованных файлов рабочих процессов можно просмотреть в указанном выходном каталоге.

Выполнение команды dry-run для конвейера выпуска

Чтобы выполнить сухой запуск миграции конвейера GitHub Actionsвыпуска Azure DevOps, выполните следующую команду в терминале, заменив pipeline_id идентификатор преобразованного конвейера.

gh actions-importer dry-run azure-devops release --pipeline-id :pipeline_id --output-dir tmp/dry-run

Журналы сухого запуска и преобразованных файлов рабочих процессов можно просмотреть в указанном выходном каталоге.

Выполнение рабочей миграции

Вы можете использовать migrate команду для преобразования конвейера Azure DevOps и открытия запроса на вытягивание с эквивалентным GitHub Actions рабочим процессом.

Выполнение команды миграции для конвейера сборки

Чтобы перенести конвейер GitHub Actionsсборки Azure DevOps, выполните следующую команду в терминале, заменив target-url значение URL-адресом репозитория GitHub и pipeline_id идентификатором преобразованного конвейера.

gh actions-importer migrate azure-devops pipeline --pipeline-id :pipeline_id --target-url https://github.com/octo-org/octo-repo --output-dir tmp/migrate

Выходные данные команды включают URL-адрес запроса на вытягивание, который добавляет преобразованный рабочий процесс в репозиторий. Пример успешного вывода аналогичен следующему:

$ 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'

Выполнение команды миграции для конвейера выпуска

Чтобы перенести конвейер GitHub Actionsвыпуска Azure DevOps, выполните следующую команду в терминале, заменив target-url значение URL-адресом репозитория GitHub и pipeline_id идентификатором преобразованного конвейера.

gh actions-importer migrate azure-devops release --pipeline-id :pipeline_id --target-url https://github.com/octo-org/octo-repo --output-dir tmp/migrate

Выходные данные команды включают URL-адрес запроса на вытягивание, который добавляет преобразованный рабочий процесс в репозиторий. Пример успешного вывода аналогичен следующему:

$ 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'

Проверка запроса на вытягивание

Выходные данные из успешного migrate выполнения команды содержат ссылку на новый запрос на вытягивание, который добавляет преобразованный рабочий процесс в репозиторий.

Ниже приведены некоторые важные элементы запроса на вытягивание:

  • В описании запроса на вытягивание раздел с именем "Вручную", в котором перечислены шаги, которые необходимо выполнить вручную, прежде чем завершить перенос конвейеров на GitHub Actions. Например, в этом разделе может быть описано создание секретов, используемых в рабочих процессах.
  • Преобразованный файл рабочих процессов. Выберите вкладку "**Измененные файлы" в запросе **на вытягивание, чтобы просмотреть файл рабочего процесса, который будет добавлен в репозиторий GitHub .

После завершения проверки запроса на вытягивание его можно объединить, чтобы добавить рабочий процесс в репозиторий GitHub .

Справочные материалы

В этом разделе содержатся справочные сведения о переменных среды, необязательных аргументах и поддерживаемом синтаксисе при GitHub Actions Importer миграции из Azure DevOps.

Переменные среды конфигурации

GitHub Actions Importer использует переменные среды для конфигурации проверки подлинности. Эти переменные задаются при выполнении процесса конфигурации с помощью configure команды. Дополнительные сведения см. в разделе "Настройка учетных данных".

GitHub Actions Importerиспользует следующие переменные среды для подключения к экземпляру Azure DevOps:

  • GITHUB_ACCESS_TOKEN personal access token (classic): используется для создания запросов на вытягивание с преобразованным рабочим процессом (требуется workflow область).
  • GITHUB_INSTANCE_URL: URL целевого GitHub экземпляра (например, https://github.com).
  • AZURE_DEVOPS_ACCESS_TOKEN personal access token: используется для проверки подлинности с помощью экземпляра Azure DevOps. Для этого маркера требуются следующие области:
    • Сборка: Read
    • Пулы агентов: Read
    • Код: Read
    • Релиз: Read
    • Подключения к службе: Read
    • Группы задач: Read
    • Группы переменных: Read
  • AZURE_DEVOPS_PROJECT: имя проекта или GUID, используемые при переносе конвейера. Если вы хотите выполнить аудит для всех проектов, это необязательно.
  • AZURE_DEVOPS_ORGANIZATION: Название организации вашего Azure DevOps инстанса.
  • AZURE_DEVOPS_INSTANCE_URL: URL Azure DevOps экземпляра, например https://dev.azure.com.

Эти переменные среды могут быть указаны в .env.local файле, который загружается в GitHub Actions Importer момент запуска.

Необязательные аргументы

Существуют необязательные аргументы, которые можно использовать с подкомандами GitHub Actions Importer для настройки миграции.

--source-file-path

Аргумент можно использовать --source-file-path с forecast``dry-runподкомандами или migrate подкомандами.

По умолчанию GitHub Actions Importer получает содержимое конвейера из системы контроля исходного кода. Аргумент --source-file-path подсказывает GitHub Actions Importer использовать указанный путь к исходному файлу.

Например:

gh actions-importer dry-run azure-devops pipeline --output-dir ./output/ --source-file-path ./path/to/azure_devops/pipeline.yml

--config-file-path

Аргумент можно использовать --config-file-path с audit``dry-runподкомандами и migrate подкомандами.

По умолчанию GitHub Actions Importer получает содержимое конвейера из системы контроля исходного кода. Аргумент --config-file-path подсказывает GitHub Actions Importer использовать указанные исходные файлы.

Аргумент --config-file-path также можно использовать для указания репозитория преобразованного повторно используемого рабочего процесса или составного действия.

Пример аудита

В этом примере GitHub Actions Importer используется указанный файл конфигурации YAML в качестве исходного файла для выполнения аудита.

gh actions-importer audit azure-devops pipeline --output-dir ./output/ --config-file-path ./path/to/azure_devops/config.yml

Для аудита Azure DevOps экземпляра с использованием конфигурационного файла конфигурационный файл должен быть в следующем формате, и каждый repository_slug должен быть уникальным:

source_files:
  - repository_slug: azdo-project/1
    path: file.yml
  - repository_slug: azdo-project/2
    paths: path.yml

Вы можете сгенерировать repository_slug для конвейера, объединив имя организации Azure DevOps, проекта и идентификатор конвейера. Например: my-organization-name/my-project-name/42.

Пример сухого запуска

В этом примере GitHub Actions Importer используется указанный конфигурационный файл YAML в качестве исходного файла для проведения пробного запуска.

Конвейер выбирается путем сопоставления repository_slug в файле конфигурации со значением и --azure-devops-organization параметром--azure-devops-project. Затем path используется для извлечения указанного исходного файла.

gh actions-importer dry-run azure-devops pipeline --output-dir ./output/ --config-file-path ./path/to/azure_devops/config.yml
Указание репозитория преобразованных повторно используемых рабочих процессов и составных действий

GitHub Actions Importer использует файл YAML, предоставленный --config-file-path аргументу, чтобы определить репозиторий, в который переносятся преобразованные повторно используемые рабочие процессы и составные действия.

Чтобы начать, необходимо выполнить аудит без аргумента --config-file-path :

gh actions-importer audit azure-devops --output-dir ./output/

Выходные данные этой команды содержат файл с именем config.yml , содержащий список всех повторно используемых рабочих процессов и составных действий, преобразованных GitHub Actions Importer. Например, config.yml файл может содержать следующее содержимое:

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

Этот файл можно использовать для указания репозитория и ссылки на повторно используемый рабочий процесс или составное действие. Затем вы можете использовать --config-file-path аргумент, чтобы предоставить config.yml файл в GitHub Actions Importer. Например, этот файл можно использовать при выполнении migrate команды, чтобы открыть запрос на вытягивание для каждого уникального репозитория, определенного в файле конфигурации:

gh actions-importer migrate azure-devops pipeline --config-file-path config.yml --target-url https://github.com/my-org/my-repo

Поддерживаемый синтаксис для Azure DevOps pipelines

В следующей таблице показаны тип объектов, которые GitHub Actions Importer в настоящее время могут конвертировать.

Azure PipelinesGitHub ActionsСостояние
condition
  • jobs.<job_id>.if
  • jobs.<job_id>.steps[*].if
Поддерживается
контейнер
  • jobs.<job_id>.container
  • jobs.<job_id>.name
Поддерживается
непрерывнаяintegration
  • on.<push>.<branches>
  • on.<push>.<tags>
  • on.<push>.paths
Поддерживается
задание
  • jobs.<job_id>
Поддерживается
pullRequest
  • on.<pull_request>.<branches>
  • on.<pull_request>.paths
Поддерживается
постановка
  • jobs
Поддерживается
steps
  • jobs.<job_id>.steps
Поддерживается
бизнеса
  • jobs.<job_id>.strategy.fail-fast
  • jobs.<job_id>.strategy.max-parallel
  • jobs.<job_id>.strategy.matrix
Поддерживается
timeoutInMinutes
  • jobs.<job_id>.timeout-minutes
Поддерживается
переменные
  • env
  • jobs.<job_id>.env
  • jobs.<job_id>.steps.env
Поддерживается
развертывание вручную
  • jobs.<job_id>.environment
Частично поддерживается
pool
  • runners
  • self hosted runners
Частично поддерживается
services;
  • jobs.<job_id>.services
Частично поддерживается
бизнеса
  • jobs.<job_id>.strategy
Частично поддерживается
триггеры
  • on
Частично поддерживается
pullRequest
  • on.<pull_request>.<tags>
Не поддерживается
schedules
  • on.schedule
  • on.workflow_run
Не поддерживается
триггеры
  • on.<event_name>.types
Не поддерживается

Для получения дополнительной информации о поддерживаемых Azure DevOps задачах см. репозиторий github/gh-actions-importer.

Сопоставление переменных среды

GitHub Actions Importerиспользует сопоставление в таблице ниже для преобразования переменных среды по умолчанию Azure DevOps в ближайший эквивалентGitHub Actions.

Azure PipelinesGitHub 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 }}

Шаблоны

Вы можете преобразовать шаблоны Azure DevOps с помощью GitHub Actions Importer.

Ограничения

GitHub Actions Importerпозволяет преобразовывать шаблоны Azure DevOps с некоторыми ограничениями.

  • Azure DevOps шаблоны, используемые в stagesразделе , deploymentsи jobs ключи преобразуются в повторно используемые рабочие процессы.GitHub Actions Дополнительные сведения см. в разделе Повторное использование рабочих процессов.
  • Azure DevOps шаблоны, используемые под ключом steps, преобразуются в составные действия. Дополнительные сведения см. в разделе Создание составного действия.
  • Если у вас есть шаблоны заданий, ссылающиеся на другие шаблоны заданий, GitHub Actions Importer преобразуйте шаблоны в повторно используемые рабочие процессы. Так как повторно используемые рабочие процессы не могут ссылаться на другие повторно используемые рабочие процессы, это недопустимый синтаксис.GitHub Actions Необходимо вручную исправить вложенные повторно используемые рабочие процессы.
  • Если шаблон ссылается на внешнюю Azure DevOps организацию или GitHub репозиторий, необходимо использовать --credentials-file этот параметр, чтобы предоставить учетные данные для доступа к этому шаблону. Дополнительные сведения см. в разделе Дополнительные аргументы и параметры.
  • Вы можете динамически создавать YAML с помощью each выражений с помощью следующих предостережения:
    • Вложенные each блоки не поддерживаются и вызывают неподдерживаемый родительский each блок.
    • each и содержащиеся if условия оцениваются во время преобразования, так как GitHub Actions не поддерживает этот стиль вставки.
    • elseif блоки не поддерживаются. Если эта функция необходима, их необходимо исправить вручную.
    • Вложенные if блоки поддерживаются, но if/elseif/else блоки, вложенные в if условие, не поддерживаются.
    • Блоки if, использующие предопределённые переменные Azure DevOps, не поддерживаются.

Поддерживаемые шаблоны

GitHub Actions Importer поддерживает шаблоны, перечисленные в таблице ниже.

Azure PipelinesGitHub ActionsСостояние
Расширение из шаблонаReusable workflowПоддерживается
Шаблоны заданияReusable workflowПоддерживается
Шаблоны этаповReusable workflowПоддерживается
Шаблоны шаговComposite actionПоддерживается
Группы задач в классическом редактореРазныеПоддерживается
Templates in a different Azure DevOps organization, project or repositoryРазныеПоддерживается
Шаблоны в репозитории GitHubРазныеПоддерживается
Шаблоны переменныхenvПоддерживается
Условное вставка
if условия задания и действияЧастично поддерживается
Итеративная вставкаНет данныхЧастично поддерживается
Шаблоны с параметрамиРазныеЧастично поддерживается

Имена путей к файлу шаблона

GitHub Actions Importer может извлекать шаблоны с относительными или динамическими путями к файлам с переменными, параметрами и итеративными выражениями в имени файла. Однако должно быть задано значение по умолчанию.

Пример имени пути к файлу переменной
# File: azure-pipelines.yml
variables:
- template: 'templates/vars.yml'

steps:
- template: "./templates/$"

# File: templates/vars.yml
variables:
  one: 'simple_step.yml'
Пример имени пути к файлу параметров
parameters:
- name: template
  type: string
  default: simple_step.yml

steps:
- template: "./templates/${{ parameters.template }}"
Пример имени пути к итеративному файлу
parameters:
- name: steps
  type: object
  default:
  - build_step
  - release_step
steps:
- ${{ each step in parameters.steps }}:
    - template: "$-variables.yml"

Параметры шаблона

GitHub Actions Importer поддерживает параметры, перечисленные в таблице ниже.

Azure PipelinesGitHub ActionsСостояние
строкаinputs.stringПоддерживается
numberinputs.numberПоддерживается
booleaninputs.booleanПоддерживается
объект
inputs.stringс выражением fromJSONЧастично поддерживается
stepstepЧастично поддерживается
stepListstepЧастично поддерживается
заданиеjobЧастично поддерживается
jobListjobЧастично поддерживается
развертываниеjobЧастично поддерживается
deploymentListjobЧастично поддерживается
постановкаjobЧастично поддерживается
stageListjobЧастично поддерживается

Примечание.

Шаблон, используемый под ключом step с этим типом параметров, сериализуется только в виде составного действия, если шаги используются в начале или конце шагов шаблона. Шаблон, используемый в разделе stage, deploymentи job ключи с этим типом параметров не преобразуются в повторно используемый рабочий процесс, а вместо этого сериализуются как автономный рабочий процесс.

Части были адаптированы в соответствии с https://github.com/github/gh-actions-importer/ лицензией MIT:

MIT License

Copyright (c) 2022 GitHub

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

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

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