Примечание. В GitHub Enterprise Server в настоящее время не поддерживаются средства выполнения тестов, размещенные в GitHub. Дополнительные сведения о планируемой поддержке в будущем см. в GitHub public roadmap.
Введение
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@v4
- 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 Enterprise Server.
Дополнительные сведения см. в разделе "[AUTOTITLE" и "Хранение сведений в переменных](/actions/security-guides/using-secrets-in-github-actions)".
Кэширование
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@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артефакты можно использовать для сохранения данных из нескольких заданий.
Ниже приведен пример синтаксиса для каждой системы.
Синтаксис CI/CD GitLab для артефактов
script:
artifacts:
paths:
- math-homework.txt
Синтаксис GitHub Actions для артефактов
- 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
.
Ниже приведен пример синтаксиса для каждой системы.
Синтаксис 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@v4
# 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
Дополнительные сведения см. в разделе Сведения о контейнерах служб.