Миграция с GitLab CI/CD на GitHub Actions

Введение

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

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

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

Задания

Задания в GitLab CI/CD очень похожи на задания в GitHub Actions. В обеих системах задания имеют следующие характеристики.

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

Вы можете выполнять в задании скрипт или команду оболочки. В GitLab CI/CD шаги скрипта указываются с помощью ключа script. В GitHub Actions все скрипты указываются с помощью ключа run.

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

job1:
  variables:
    GIT_CHECKOUT: "true"
  script:
    - echo "Run your script here"

jobs:
  job1:
    steps:
      - uses: actions/checkout@v3
      - run: echo "Run your script here"

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

Средства выполнения — это виртуальные машины, на которых выполняются задания. GitLab CI/CD и GitHub Actions предлагают управляемые и локальные варианты средств выполнения. В GitLab CI/CD для выполнения заданий на разных платформах используются tags, а в GitHub Actions это делается с помощью ключа runs-on.

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

windows_job:
  tags:
    - windows
  script:
    - echo Hello, %USERNAME%!

linux_job: tags:
    - linux script:
    - echo "Hello, $USER!"

windows_job:
  runs-on: windows-latest
  steps:
    - run: echo Hello, %USERNAME%!

linux_job:
  runs-on: ubuntu-latest
  steps:
    - run: echo "Hello, $USER!"

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

Образы Docker

GitLab CI/CD и GitHub Actions поддерживают выполнение заданий в образе Docker. В GitLab CI/CD образы Docker определяются с помощью ключа image, а в GitHub Actions это делается с помощью ключа container.

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

my_job:
  image: node:10.16-jessie

jobs:
  my_job:
    container: node:10.16-jessie

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

Синтаксис условий и выражений

GitLab CI/CD использует rules для определения, будет ли задание выполняться при определенном условии. В GitHub Actions используется ключевое слово if, чтобы предотвратить выполнение задания, если условие не выполняется.

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

deploy_prod:
  stage: deploy
  script:
    - echo "Deploy to production server"
  rules:
    - if: '$CI_COMMIT_BRANCH == "master"'

jobs:
  deploy_prod:
    if: contains( github.ref, 'master')
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploy to production server"

Дополнительные сведения см. в разделе Выражения.

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

И GitLab CI/CD, и GitHub Actions позволяют задавать зависимости для задания. В обеих системах задания по умолчанию выполняются параллельно, но зависимости заданий в GitHub Actions можно указывать явным образом с помощью ключа needs. В GitLab CI/CD также имеется концепция stages, в которой задания в этапе выполняются параллельно, но следующий этап начнется после завершения всех заданий предыдущего этапа. Этот сценарий можно воссоздать в GitHub Actions с помощью ключа needs.

Ниже приведен пример синтаксиса для каждой системы. Рабочие процессы начинаются с двух заданий с именами build_a и build_b, выполняющихся параллельно, а после завершения этих заданий будет выполняться другое задание с именем test_ab. Наконец, по завершении задания test_ab, будет выполняться задание deploy_ab.

stages:
  - build
  - test
  - deploy

build_a: stage: build script:
    - echo "This job will run first."

build_b: stage: build script:
    - echo "This job will run first, in parallel with build_a."

test_ab: stage: test script:
    - echo "This job will run after build_a and build_b have finished."

deploy_ab: stage: deploy script:
    - echo "This job will run after test_ab is complete"

jobs:
  build_a:
    runs-on: ubuntu-latest
    steps:
      - run: echo "This job will be run first."

  build_b:
    runs-on: ubuntu-latest
    steps:
      - run: echo "This job will be run first, in parallel with build_a"

  test_ab:
    runs-on: ubuntu-latest
    needs: [build_a,build_b]
    steps:
      - run: echo "This job will run after build_a and build_b have finished"

  deploy_ab:
    runs-on: ubuntu-latest
    needs: [test_ab]
    steps:
      - run: echo "This job will run after test_ab is complete"

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

Планирование рабочих процессов

GitLab CI/CD и GitHub Actions позволяют запускать рабочие процессы через определенный интервал. В GitLab CI/CD расписания конвейера настраиваются с помощью пользовательского интерфейса, а в GitHub Actions можно активировать рабочий процесс с запланированным интервалом с помощью ключа "on".

Дополнительные сведения см. в разделе События, инициирующие рабочие процессы.

Переменные и секреты

GitLab CI/CD и GitHub Actions поддерживают переменные параметров в файле конфигурации конвейера или рабочего процесса и создают секреты с помощью пользовательского интерфейса GitLab или GitHub Enterprise Server.

Дополнительные сведения см. в разделах Переменные и Зашифрованные секреты.

Кэширование

GitLab CI/CD и GitHub Actions предоставляют метод в файле конфигурации для ручного кэширования файлов рабочего процесса.

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

image: node:latest

cache: key: $CI_COMMIT_REF_SLUG paths:
    - .npm/

before_script:
  - npm ci --cache .npm --prefer-offline

test_async: script:
    - node ./specs/start.js ./specs/async.spec.js

jobs:
  test_async:
    runs-on: ubuntu-latest
    steps:
    - name: Cache node modules
      uses: actions/cache@v3
      with:
        path: ~/.npm
        key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
        restore-keys: v1-npm-deps-

Artifacts

Как GitLab CI/CD, так и GitHub Actions могут отправлять файлы и каталоги, созданные заданием, как артефакты. В GitHub Actionsартефакты можно использовать для сохранения данных из нескольких заданий.

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

script:
artifacts:
  paths:
    - math-homework.txt

- name: Upload math result for job 1
  uses: actions/upload-artifact@v3
  with:
    name: homework
    path: math-homework.txt

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

Базы данных и контейнеры служб

Обе системы позволяют включать дополнительные контейнеры для баз данных, кэширования или других зависимостей.

В GitLab CI/CD контейнер для задания указывается с помощью ключа image, а в GitHub Actions используется ключ container. Дополнительные контейнеры служб в обеих системах указываются с помощью ключа services.

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

container-job:
  variables:
    POSTGRES_PASSWORD: postgres
    # The hostname used to communicate with the
    # PostgreSQL service container
    POSTGRES_HOST: postgres
    # The default PostgreSQL port
    POSTGRES_PORT: 5432
  image: node:10.18-jessie
  services:
    - postgres
  script:
    # Performs a clean installation of all dependencies
    # in the `package.json` file
    - npm ci
    # Runs a script that creates a PostgreSQL client,
    # populates the client with data, and retrieves data
    - node client.js
  tags:
    - docker

jobs:
  container-job:
    runs-on: ubuntu-latest
    container: node:10.18-jessie

    services:
      postgres:
        image: postgres
        env:
          POSTGRES_PASSWORD: postgres

    steps:
      - name: Check out repository code
        uses: actions/checkout@v3

      # Performs a clean installation of all dependencies
      # in the `package.json` file
      - name: Install dependencies
        run: npm ci

      - name: Connect to PostgreSQL
        # Runs a script that creates a PostgreSQL client,
        # populates the client with data, and retrieves data
        run: node client.js
        env:
          # The hostname used to communicate with the
          # PostgreSQL service container
          POSTGRES_HOST: postgres
          # The default PostgreSQL port
          POSTGRES_PORT: 5432

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