Skip to main content

Миграция с 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.

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

Синтаксис CI/CD GitLab для заданий

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

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

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

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

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

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

Синтаксис CI/CD GitLab для runners

windows_job: tags: - windows script: - echo Hello, %USERNAME%! linux_job: tags: - linux script: - echo "Hello, $USER!" 

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

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.

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

Синтаксис CI/CD GitLab для образов Docker

my_job: image: node:20-bookworm-slim 

Синтаксис GitHub Actions для образов Docker

jobs: my_job: container: node:20-bookworm-slim 

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

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

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

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

Синтаксис CI/CD GitLab для условий и выражений

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

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

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.

Синтаксис CI/CD GitLab для зависимостей между заданиями

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" 

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

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 .

Дополнительные сведения см. в разделе [AUTOTITLE и Хранение сведений в переменных](/actions/security-for-github-actions/security-guides/about-secrets).

Кэширование

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

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

Синтаксис CI/CD GitLab для кэширования

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 

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

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

Artifacts

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

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

Синтаксис CI/CD GitLab для артефактов

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

Синтаксис GitHub Actions для артефактов

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

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

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

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

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

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

Синтаксис CI/CD GitLab для баз данных и контейнеров служб

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:20-bookworm-slim 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 

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

jobs: container-job: runs-on: ubuntu-latest container: node:20-bookworm-slim services: postgres: image: postgres env: POSTGRES_PASSWORD: postgres steps: - name: Check out repository code uses: actions/checkout@v5 # 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 

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