Введение
CircleCI и GitHub Actions позволяют создавать рабочие процессы, которые автоматически выполняют сборку, тестирование, публикацию, выпуск и развертывание кода. CircleCI и GitHub Actions используют некоторые сходства в конфигурации рабочего процесса.
- Файлы конфигурации рабочего процесса записываются в YAML и хранятся в репозитории.
- В рабочем процессе может быть одно или несколько заданий.
- Задания включают один или несколько шагов или отдельных команд.
- Шаги или задачи можно повторно использовать и предоставлять сообществу.
Дополнительные сведения см. в разделе Общие сведения о GitHub Actions.
Основные различия
При миграции с CircleCI необходимо учитывать следующие различия.
- Автоматический параллелизм тестов в CircleCI автоматически группирует тесты в соответствии с заданными пользователем правилами или историческими сведениями о времени. Эта функциональность не встроена в GitHub Actions.
- Действия, выполняемые в контейнерах Docker, чувствительны к проблемам с разрешениями, так как в контейнерах используется другое сопоставление пользователей. Многих из этих проблем можно избежать, не используя инструкцию
USER
в Dockerfile. Дополнительные сведения о файловой системе Docker в средствах выполнения тестов, размещенных в GitHub Enterprise Cloud, см. в разделе О средствах выполнения, размещенных в GitHub.
Миграция рабочих процессов и заданий
CircleCI определяет workflows
в файле config.yml, что позволяет настроить несколько рабочих процессов. В GitHub Enterprise Cloud требуется по одному файлу рабочего процесса для каждого рабочего процесса, и, как следствие, не требуется объявление workflows
. Вам нужно будет создать по новому файлу рабочего процесса для каждого рабочего процесса, настроенного в файле config.yml.
Как CircleCI, так и GitHub Actions настраивают jobs
в файле конфигурации с использованием аналогичного синтаксиса. При настройке зависимостей между заданиями с помощью requires
в рабочем процессе CircleCI вы можете использовать эквивалентный синтаксис needs
GitHub Actions. Дополнительные сведения см. в разделе Синтаксис рабочего процесса для GitHub Actions.
Перенос orbs в действия
И CircleCI, и GitHub Actions предоставляют механизм повторного использования и совместного использования задач в рабочем процессе. CircleCI использует концепцию с именем orbs, написанную в YAML, для предоставления задач, которые пользователи могут повторно использовать в рабочем процессе. GitHub Actions имеет мощные и гибкие многократно используемые компоненты, называемые действиями, которые создаются с помощью файлов JavaScript или образов Docker. Вы можете создавать действия путем написания специального кода, взаимодействующего с репозиторием любым желательным вам способом, включая интеграцию с API GitHub Enterprise Cloud и любым общедоступным сторонним API. Например, действие может публиковать модули NPM, отправлять SMS-оповещения при возникновении неотложных проблем или развертывать готовый код. Дополнительные сведения см. в разделе Создание действий.
CircleCI может повторно использовать фрагменты рабочих процессов с привязками и псевдонимами YAML. GitHub Actions поддерживает наиболее распространенную потребность в повторном использовании с помощью матриц. Дополнительные сведения о матрицах см. в разделе Использование матрицы для заданий.
Использование образов Docker
И CircleCI, и GitHub Actions поддерживают выполнение шагов внутри образа Docker.
CircleCI предоставляет набор предварительно созданных образов с общими зависимостями. В этих образах USER
настроен как circleci
, что приводит к конфликту разрешений с GitHub Actions.
Рекомендуется отказаться от предварительно созданных образов CircleCI при миграции на GitHub Actions. Во многих случаях вы можете использовать действия для установки необходимых дополнительных зависимостей.
Дополнительные сведения о файловой системе Docker см. в разделе О средствах выполнения, размещенных в GitHub.
Дополнительные сведения о средствах и пакетах, доступных в образах средств выполнения тестов, размещенных в GitHub, см. в разделе О средствах выполнения, размещенных в GitHub.
Использование переменных и секретов
CircleCI и GitHub Actions поддерживают переменные настройки в файле конфигурации и создание секретов с помощью пользовательского интерфейса CircleCI или GitHub Enterprise Cloud.
Дополнительные сведения см. в разделах Переменные и Зашифрованные секреты.
Кэширование
CircleCI и GitHub Actions предоставляют метод для ручного кэширования файлов в файле конфигурации.
Ниже приведен пример синтаксиса для каждой системы.
CircleCI | Действия GitHub |
---|---|
|
|
В GitHub Actions отсутствует эквивалент кэширования уровня Docker (или DLC) CircleCI.
Сохранение данных между заданиями
И CircleCI, и GitHub Actions предоставляют механизмы сохранения данных между заданиями.
Ниже приведен пример синтаксиса конфигурации в CircleCI и GitHub Actions.
CircleCI | Действия GitHub |
---|---|
|
|
Дополнительные сведения см. в разделе Хранение данных рабочего процесса в виде артефактов.
Использование баз данных и контейнеров служб
Обе системы позволяют включать дополнительные контейнеры для баз данных, кэширования или других зависимостей.
В CircleCI первый образ, указанный в файле config.yaml, является основным образом, используемым для выполнения команд. GitHub Actions использует явные разделы: container
используется для основного контейнера, и дополнительные контейнеры перечисляются в services
.
Ниже приведен пример синтаксиса конфигурации в CircleCI и GitHub Actions.
CircleCI | Действия GitHub |
---|---|
|
|
Дополнительные сведения см. в разделе Сведения о контейнерах служб.
Полный пример
Ниже приведен пример из практики. В левой части показан фактический файл config.yml CircleCI для репозиторияthoughtbot/administrator. Справа показан эквивалент в GitHub Actions.
CircleCI | Действия GitHub |
---|---|
|
|