Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

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

GitHub Actions и 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.

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

GitLab CI/CD GitHub Actions
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.

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

GitLab CI/CD GitHub Actions
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.

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

GitLab CI/CD GitHub Actions
my_job:
  image: node:10.16-jessie
jobs:
  my_job:
    container: node:10.16-jessie

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

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

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

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

GitLab CI/CD GitHub Actions
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.

GitLab CI/CD GitHub Actions
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 Cloud.

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

Кэширование

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

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

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артефакты можно использовать для сохранения данных из нескольких заданий.

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

GitLab CI/CD 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.

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

GitLab CI/CD GitHub Actions
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

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