# Переход с 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 для заданий

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

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

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

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

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

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

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

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

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

### GitHub Actions синтаксис для runners

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

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

Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idruns-on).

## Образы Docker

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

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

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

```yaml
my_job:
  image: node:20-bookworm-slim
```

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

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

Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idcontainer).

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

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

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

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

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

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

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

Дополнительные сведения см. в разделе [Оценка выражений в рабочих процессах и действиях](/ru/actions/reference/workflows-and-actions/expressions).

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

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 для зависимостей между заданиями

```yaml
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 синтаксис для зависимостей между заданиями

```yaml
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](/ru/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idneeds).

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

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

Дополнительные сведения см. в разделе [События, инициирующие рабочие процессы](/ru/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule).

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

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

Дополнительные сведения см. в разделе \[AUTOTITLE и [Хранение сведений в переменных](/ru/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables)]\(/actions/concepts/security/secrets).

## Кэширование

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

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

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

```yaml
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 синтаксис кэширования

```yaml
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

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

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

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

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

### GitHub Actions синтаксис артефактов

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

Дополнительные сведения см. в разделе [Хранение и предоставление общего доступа к данным с артефактами рабочего процесса](/ru/actions/tutorials/store-and-share-data).

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

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

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

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

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

```yaml
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 синтаксис для баз данных и контейнеров служб

```yaml
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@v6

      # 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](/ru/actions/tutorials/use-containerized-services/use-docker-service-containers).