{"meta":{"title":"Переход с GitLab CI/CD на GitHub Actions","intro":"GitHub Actions и GitLab CI/CD имеют несколько сходств в конфигурации, что делает миграцию на GitHub Actions относительно простой.","product":"GitHub Actions","breadcrumbs":[{"href":"/ru/actions","title":"GitHub Actions"},{"href":"/ru/actions/tutorials","title":"Учебники"},{"href":"/ru/actions/tutorials/migrate-to-github-actions","title":"Миграция на GitHub Actions"},{"href":"/ru/actions/tutorials/migrate-to-github-actions/manual-migrations","title":"Миграция вручную"},{"href":"/ru/actions/tutorials/migrate-to-github-actions/manual-migrations/migrate-from-gitlab-cicd","title":"Миграция из GitLab CI/CD"}],"documentType":"article"},"body":"# Переход с GitLab CI/CD на GitHub Actions\n\nGitHub Actions и GitLab CI/CD имеют несколько сходств в конфигурации, что делает миграцию на GitHub Actions относительно простой.\n\n## Введение\n\nGitLab CI/CD и GitHub Actions позволяют создавать рабочие процессы, которые автоматически выполняют сборку, тестирование, публикацию, выпуск и развертывание кода. GitLab CI/CD и GitHub Actions используют некоторые сходства в конфигурации рабочего процесса.\n\n* Файлы конфигурации рабочего процесса записываются в YAML и хранятся в репозитории кода.\n* В рабочем процессе может быть одно или несколько заданий.\n* Задания включают один или несколько шагов или отдельных команд.\n* Задания могут выполняться на управляемых или локальных компьютерах.\n\nСуществуют некоторые различия, и в этом руководстве показаны наиболее важные из них, чтобы вы могли перенести свой рабочий процесс в GitHub Actions.\n\n## Работы\n\nЗадания в GitLab CI/CD очень похожи на задания в GitHub Actions. В обеих системах задания имеют следующие характеристики.\n\n* Задания содержат ряд шагов или скриптов, которые выполняются последовательно.\n* Задания могут выполняться на отдельных виртуальных машинах или в отдельных контейнерах.\n* По умолчанию задания выполняются параллельно, но можно настроить их последовательное выполнение.\n\nВы можете выполнять в задании скрипт или команду оболочки. В GitLab CI/CD шаги скрипта указываются с помощью ключа `script`. В GitHub Actions все скрипты указываются с помощью ключа `run`.\n\nНиже приведен пример синтаксиса для каждой системы.\n\n### Синтаксис CI/CD GitLab для заданий\n\n```yaml\njob1:\n  variables:\n    GIT_CHECKOUT: \"true\"\n  script:\n    - echo \"Run your script here\"\n```\n\n### Синтаксис GitHub Actions для заданий\n\n```yaml\njobs:\n  job1:\n    steps:\n      - uses: actions/checkout@v6\n      - run: echo \"Run your script here\"\n```\n\n## Средства выполнения\n\nСредства выполнения — это виртуальные машины, на которых выполняются задания. GitLab CI/CD и GitHub Actions предлагают управляемые и локальные варианты средств выполнения. В GitLab CI/CD для выполнения заданий на разных платформах используются `tags`, а в GitHub Actions это делается с помощью ключа `runs-on`.\n\nНиже приведен пример синтаксиса для каждой системы.\n\n### Синтаксис CI/CD GitLab для runners\n\n```yaml\nwindows_job:\n  tags:\n    - windows\n  script:\n    - echo Hello, %USERNAME%!\n\nlinux_job:\n  tags:\n    - linux\n  script:\n    - echo \"Hello, $USER!\"\n```\n\n### Синтаксис GitHub Actions для средств выполнения\n\n```yaml\nwindows_job:\n  runs-on: windows-latest\n  steps:\n    - run: echo Hello, %USERNAME%!\n\nlinux_job:\n  runs-on: ubuntu-latest\n  steps:\n    - run: echo \"Hello, $USER!\"\n```\n\nДополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on).\n\n## Образы Docker\n\nGitLab CI/CD и GitHub Actions поддерживают выполнение заданий в образе Docker. В GitLab CI/CD образы Docker определяются с помощью ключа `image`, а в GitHub Actions это делается с помощью ключа `container`.\n\nНиже приведен пример синтаксиса для каждой системы.\n\n### Синтаксис CI/CD GitLab для образов Docker\n\n```yaml\nmy_job:\n  image: node:20-bookworm-slim\n```\n\n### Синтаксис GitHub Actions для образов Docker\n\n```yaml\njobs:\n  my_job:\n    container: node:20-bookworm-slim\n```\n\nДополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontainer).\n\n## Синтаксис условий и выражений\n\nGitLab CI/CD использует `rules` для определения, будет ли задание выполняться при определенном условии. В GitHub Actions используется ключевое слово `if`, чтобы предотвратить выполнение задания, если условие не выполняется.\n\nНиже приведен пример синтаксиса для каждой системы.\n\n### Синтаксис CI/CD GitLab для условий и выражений\n\n```yaml\ndeploy_prod:\n  stage: deploy\n  script:\n    - echo \"Deploy to production server\"\n  rules:\n    - if: '$CI_COMMIT_BRANCH == \"master\"'\n```\n\n### Синтаксис GitHub Actions для условий и выражений\n\n```yaml\njobs:\n  deploy_prod:\n    if: contains( github.ref, 'master')\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"Deploy to production server\"\n```\n\nДополнительные сведения см. в разделе [Оценка выражений в рабочих процессах и действиях](/ru/actions/learn-github-actions/expressions).\n\n## Зависимости между заданиями\n\nИ GitLab CI/CD, и GitHub Actions позволяют задавать зависимости для задания. В обеих системах задания по умолчанию выполняются параллельно, но зависимости заданий в GitHub Actions можно указывать явным образом с помощью ключа `needs`. В GitLab CI/CD также имеется концепция `stages`, в которой задания в этапе выполняются параллельно, но следующий этап начнется после завершения всех заданий предыдущего этапа. Этот сценарий можно воссоздать в GitHub Actions с помощью ключа `needs`.\n\nНиже приведен пример синтаксиса для каждой системы. Рабочие процессы начинаются с двух заданий с именами `build_a` и `build_b`, выполняющихся параллельно, а после завершения этих заданий будет выполняться другое задание с именем `test_ab`. Наконец, по завершении задания `test_ab`, будет выполняться задание `deploy_ab`.\n\n### Синтаксис CI/CD GitLab для зависимостей между заданиями\n\n```yaml\nstages:\n  - build\n  - test\n  - deploy\n\nbuild_a:\n  stage: build\n  script:\n    - echo \"This job will run first.\"\n\nbuild_b:\n  stage: build\n  script:\n    - echo \"This job will run first, in parallel with build_a.\"\n\ntest_ab:\n  stage: test\n  script:\n    - echo \"This job will run after build_a and build_b have finished.\"\n\ndeploy_ab:\n  stage: deploy\n  script:\n    - echo \"This job will run after test_ab is complete\"\n```\n\n### Синтаксис GitHub Actions для зависимостей между заданиями\n\n```yaml\njobs:\n  build_a:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"This job will be run first.\"\n\n  build_b:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"This job will be run first, in parallel with build_a\"\n\n  test_ab:\n    runs-on: ubuntu-latest\n    needs: [build_a,build_b]\n    steps:\n      - run: echo \"This job will run after build_a and build_b have finished\"\n\n  deploy_ab:\n    runs-on: ubuntu-latest\n    needs: [test_ab]\n    steps:\n      - run: echo \"This job will run after test_ab is complete\"\n```\n\nДополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds).\n\n## Планирование рабочих процессов\n\nGitLab CI/CD и GitHub Actions позволяют запускать рабочие процессы через определенный интервал. В GitLab CI/CD расписания конвейера настраиваются с помощью пользовательского интерфейса, а в GitHub Actions можно активировать рабочий процесс с запланированным интервалом с помощью ключа \"on\".\n\nДополнительные сведения см. в разделе [События, инициирующие рабочие процессы](/ru/actions/using-workflows/events-that-trigger-workflows#scheduled-events).\n\n## Переменные и секреты\n\nGitLab CI/CD и GitHub Actions поддерживают переменные в файле конфигурации конвейера или рабочего процесса и создают секреты с помощью пользовательского интерфейса GitLab или GitHub .\n\nДополнительные сведения см. в разделе \\[AUTOTITLE и [Хранение сведений в переменных](/ru/actions/learn-github-actions/variables)]\\(/actions/security-for-github-actions/security-guides/about-secrets).\n\n## Кэширование\n\nGitLab CI/CD и GitHub Actions предоставляют метод в файле конфигурации для ручного кэширования файлов рабочего процесса.\n\nНиже приведен пример синтаксиса для каждой системы.\n\n### Синтаксис CI/CD GitLab для кэширования\n\n```yaml\nimage: node:latest\n\ncache:\n  key: $CI_COMMIT_REF_SLUG\n  paths:\n    - .npm/\n\nbefore_script:\n  - npm ci --cache .npm --prefer-offline\n\ntest_async:\n  script:\n    - node ./specs/start.js ./specs/async.spec.js\n```\n\n### Синтаксис GitHub Actions для кэширования\n\n```yaml\njobs:\n  test_async:\n    runs-on: ubuntu-latest\n    steps:\n    - name: Cache node modules\n      uses: actions/cache@v4\n      with:\n        path: ~/.npm\n        key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}\n        restore-keys: v1-npm-deps-\n```\n\n## Artifacts\n\nКак GitLab CI/CD, так и GitHub Actions могут отправлять файлы и каталоги, созданные заданием, как артефакты. В GitHub Actionsартефакты можно использовать для сохранения данных из нескольких заданий.\n\nНиже приведен пример синтаксиса для каждой системы.\n\n### Синтаксис CI/CD GitLab для артефактов\n\n```yaml\nscript:\nartifacts:\n  paths:\n    - math-homework.txt\n```\n\n### Синтаксис GitHub Actions для артефактов\n\n```yaml\n- name: Upload math result for job 1\n  uses: actions/upload-artifact@v4\n  with:\n    name: homework\n    path: math-homework.txt\n```\n\nДополнительные сведения см. в разделе [Хранение и предоставление общего доступа к данным с артефактами рабочего процесса](/ru/actions/using-workflows/storing-workflow-data-as-artifacts).\n\n## Базы данных и контейнеры служб\n\nОбе системы позволяют включать дополнительные контейнеры для баз данных, кэширования или других зависимостей.\n\nВ GitLab CI/CD контейнер для задания указывается с помощью ключа `image`, а в GitHub Actions используется ключ `container`. Дополнительные контейнеры служб в обеих системах указываются с помощью ключа `services`.\n\nНиже приведен пример синтаксиса для каждой системы.\n\n### Синтаксис CI/CD GitLab для баз данных и контейнеров служб\n\n```yaml\ncontainer-job:\n  variables:\n    POSTGRES_PASSWORD: postgres\n    # The hostname used to communicate with the\n    # PostgreSQL service container\n    POSTGRES_HOST: postgres\n    # The default PostgreSQL port\n    POSTGRES_PORT: 5432\n  image: node:20-bookworm-slim\n  services:\n    - postgres\n  script:\n    # Performs a clean installation of all dependencies\n    # in the `package.json` file\n    - npm ci\n    # Runs a script that creates a PostgreSQL client,\n    # populates the client with data, and retrieves data\n    - node client.js\n  tags:\n    - docker\n```\n\n### Синтаксис GitHub Actions для баз данных и контейнеров служб\n\n```yaml\njobs:\n  container-job:\n    runs-on: ubuntu-latest\n    container: node:20-bookworm-slim\n\n    services:\n      postgres:\n        image: postgres\n        env:\n          POSTGRES_PASSWORD: postgres\n\n    steps:\n      - name: Check out repository code\n        uses: actions/checkout@v6\n\n      # Performs a clean installation of all dependencies\n      # in the `package.json` file\n      - name: Install dependencies\n        run: npm ci\n\n      - name: Connect to PostgreSQL\n        # Runs a script that creates a PostgreSQL client,\n        # populates the client with data, and retrieves data\n        run: node client.js\n        env:\n          # The hostname used to communicate with the\n          # PostgreSQL service container\n          POSTGRES_HOST: postgres\n          # The default PostgreSQL port\n          POSTGRES_PORT: 5432\n```\n\nДополнительные сведения см. в разделе [Взаимодействие с контейнерами служб Docker](/ru/actions/using-containerized-services/about-service-containers)."}