Skip to main content

Миграция с Azure Pipelines на GitHub Actions

GitHub Actions и Azure Pipelines имеют несколько сходств в конфигурации, что делает миграцию на GitHub Actions относительно простой.

Примечание. В GitHub Enterprise Server в настоящее время не поддерживаются средства выполнения тестов, размещенные в GitHub. Дополнительные сведения о планируемой поддержке в будущем см. в GitHub public roadmap.

Введение

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

  • Файлы конфигурации рабочего процесса записываются в YAML и хранятся в репозитории кода.
  • В рабочем процессе может быть одно или несколько заданий.
  • Задания включают один или несколько шагов или отдельных команд.
  • Шаги или задачи можно повторно использовать и предоставлять сообществу.

Дополнительные сведения см. в разделе Общие сведения о GitHub Actions.

Основные отличия

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

  • Azure Pipelines поддерживает устаревший классический редактор, который позволяет определить конфигурацию CI в редакторе графического пользовательского интерфейса вместо создания определения конвейера в файле YAML. GitHub Actions использует файлы YAML для определения рабочих процессов и не поддерживает графический редактор.
  • Azure Pipelines позволяет пропускать некоторые структуры в определениях заданий. Например, если у вас есть только одно задание, вам не нужно определять само задание, достаточно определить его шаги. GitHub Actions требует явной настройки, и в структуре YAML нельзя делать пропуски.
  • Azure Pipelines поддерживает этапы, определенные в файле YAML, которые можно использовать для создания рабочих процессов развертывания. GitHub Actions требует разделять этапы на отдельные файлы рабочих процессов YAML.
  • Локальные агенты сборки Azure Pipelines можно выбирать с определенными возможностями. Локальные средства выполнения GitHub Actions можно выбирать с определенными метками.

Миграция заданий и шагов

Задания и шаги в Azure Pipelines очень похожи на задания и шаги в GitHub Actions. В обеих системах задания имеют следующие характеристики.

  • Задания содержат ряд шагов, которые выполняются последовательно.
  • Задания выполняются на отдельных виртуальных машинах или в отдельных контейнерах.
  • По умолчанию задания выполняются параллельно, но можно настроить их последовательное выполнение.

Миграция шагов скрипта

Скрипт или команду оболочки можно выполнять как шаг рабочего процесса. В Azure Pipelines шаги скрипта можно указать с помощью ключа script или с использованием ключей bash, powershell или pwsh. Скрипты также можно указать в качестве входных данных задачи Bash или задачи PowerShell.

В GitHub Actions все скрипты указываются с помощью ключа run. Чтобы выбрать конкретную оболочку, можно указать ключ shell при предоставлении скрипта. Дополнительные сведения см. в разделе Синтаксис рабочего процесса для GitHub Actions.

Ниже приведен пример синтаксиса для каждой системы.

Синтаксис Azure Pipelines для шагов скрипта

jobs:
  - job: scripts
    pool:
      vmImage: 'windows-latest'
    steps:
      - script: echo "This step runs in the default shell"
      - bash: echo "This step runs in bash"
      - pwsh: Write-Host "This step runs in PowerShell Core"
      - task: PowerShell@2
        inputs:
          script: Write-Host "This step runs in PowerShell"

Синтаксис GitHub Actions для шагов скрипта

jobs:
  scripts:
    runs-on: windows-latest
    steps:
      - run: echo "This step runs in the default shell"
      - run: echo "This step runs in bash"
        shell: bash
      - run: Write-Host "This step runs in PowerShell Core"
        shell: pwsh
      - run: Write-Host "This step runs in PowerShell"
        shell: powershell

Различия в обработке ошибок скрипта

В Azure Pipelines скрипты можно настроить так, чтобы они выдавали ошибку, если какие-либо выходные данные отправляются в stderr. GitHub Actions не поддерживает эту конфигурацию.

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

Различия в оболочке по умолчанию в Windows

В Azure Pipelines оболочкой по умолчанию для скриптов на платформах Windows платформах является командная оболочка (cmd.exe). В GitHub Actionsоболочкой по умолчанию для скриптов на платформах Windows является PowerShell. PowerShell имеет некоторые различия во встроенных командах, расширении переменных и управлении потоком.

Если вы выполняете простую команду, то можете запустить скрипт командной оболочки в PowerShell без каких-либо изменений. Но в большинстве случаев вам потребуется обновить скрипт с учетом синтаксиса PowerShell или указать GitHub Actions, что скрипт следует запускать с помощью командной оболочки вместо PowerShell. Это можно сделать, задав для shell значение cmd.

Ниже приведен пример синтаксиса для каждой системы.

Синтаксис Azure Pipelines с помощью CMD по умолчанию

jobs:
  - job: run_command
    pool:
      vmImage: 'windows-latest'
    steps:
      - script: echo "This step runs in CMD on Windows by default"

Синтаксис GitHub Actions для указания CMD

jobs:
  run_command:
    runs-on: windows-latest
    steps:
      - run: echo "This step runs in PowerShell on Windows by default"
      - run: echo "This step runs in CMD on Windows explicitly"
        shell: cmd

Дополнительные сведения см. в разделе Синтаксис рабочего процесса для GitHub Actions.

Миграция условных выражений и синтаксис выражений

Azure Pipelines и GitHub Actions могут выполнять шаги условно. В Azure Pipelines условные выражения задаются с помощью ключа condition. В GitHub Actionsусловные выражения задаются с помощью ключа if.

Azure Pipelines использует функции в выражениях для условного выполнения шагов. В отличие от этого, GitHub Actions использует нотацию infix. Например, необходимо заменить функцию eq в Azure Pipelines оператором == в GitHub Actions.

Ниже приведен пример синтаксиса для каждой системы.

Синтаксис Azure Pipelines для условных выражений

jobs:
  - job: conditional
    pool:
      vmImage: 'ubuntu-latest'
    steps:
      - script: echo "This step runs with str equals 'ABC' and num equals 123"
        condition: and(eq(variables.str, 'ABC'), eq(variables.num, 123))

Синтаксис GitHub Actions для условных выражений

jobs:
  conditional:
    runs-on: ubuntu-latest
    steps:
      - run: echo "This step runs with str equals 'ABC' and num equals 123"
        if: ${{ env.str == 'ABC' && env.num == 123 }}

Дополнительные сведения см. в разделе Оценка выражений в рабочих процессах и действиях.

Зависимости между заданиями

И Azure Pipelines, и GitHub Actions позволяют задавать зависимости для задания. В обеих системах задания по умолчанию выполняются параллельно, но зависимости заданий можно указывать явным образом. В Azure Pipelines это делается с помощью ключа dependsOn. В GitHub Actionsэто делается с помощью ключа needs.

Ниже приведен пример синтаксиса для каждой системы. Рабочие процессы запускают первое задание с именем initial, и после завершения этого задания будут выполняться два задания с именами fanout1 и fanout2. И наконец, после завершения этих заданий, будет выполняться задание fanin.

Синтаксис Azure Pipelines для зависимостей между заданиями

jobs:
  - job: initial
    pool:
      vmImage: 'ubuntu-latest'
    steps:
      - script: echo "This job will be run first."
  - job: fanout1
    pool:
      vmImage: 'ubuntu-latest'
    dependsOn: initial
    steps:
      - script: echo "This job will run after the initial job, in parallel with fanout2."
  - job: fanout2
    pool:
      vmImage: 'ubuntu-latest'
    dependsOn: initial
    steps:
      - script: echo "This job will run after the initial job, in parallel with fanout1."
  - job: fanin:
    pool:
      vmImage: 'ubuntu-latest'
    dependsOn: [fanout1, fanout2]
    steps:
      - script: echo "This job will run after fanout1 and fanout2 have finished."

Синтаксис GitHub Actions для зависимостей между заданиями

jobs:
  initial:
    runs-on: ubuntu-latest
    steps:
      - run: echo "This job will be run first."
  fanout1:
    runs-on: ubuntu-latest
    needs: initial
    steps:
      - run: echo "This job will run after the initial job, in parallel with fanout2."
  fanout2:
    runs-on: ubuntu-latest
    needs: initial
    steps:
      - run: echo "This job will run after the initial job, in parallel with fanout1."
  fanin:
    runs-on: ubuntu-latest
    needs: [fanout1, fanout2]
    steps:
      - run: echo "This job will run after fanout1 and fanout2 have finished."

Дополнительные сведения см. в разделе Синтаксис рабочего процесса для GitHub Actions.

Миграция задач в действия

Azure Pipelines использует задачи, являющиеся компонентами приложения, которые можно повторно использовать в нескольких рабочих процессах. GitHub Actions использует действия, которые можно использовать для выполнения задач и настройки рабочего процесса. В обеих системах можно указать имя задачи или действия для выполнения, а также все необходимые входные данные в виде пар "ключ-значение".

Ниже приведен пример синтаксиса для каждой системы.

Синтаксис Azure Pipelines для задач

jobs:
  - job: run_python
    pool:
      vmImage: 'ubuntu-latest'
    steps:
      - task: UsePythonVersion@0
        inputs:
          versionSpec: '3.7'
          architecture: 'x64'
      - script: python script.py

Синтаксис GitHub Actions для действий

jobs:
  run_python:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-python@v5
        with:
          python-version: '3.7'
          architecture: 'x64'
      - run: python script.py

Вы можете найти действия для использования в рабочих процессах в GitHub Marketplace или создать свои собственные действия. Дополнительные сведения см. в разделе Совместное использование автоматизации.