Поиск по сайту:

Как настроить конвейер CI на GitLab

Непрерывная интеграция (CI) означает, что изменения кода создаются и тестируются автоматически. Вот как я настроил конвейер CI для своего проекта на C++.

В этой статье рассматривается настройка конвейера CI для проекта C++ на GitLab. В моих предыдущих статьях рассказывалось, как настроить систему сборки на основе CMake и VSCodium и как интегрировать модульные тесты на основе GoogleTest и CTest. Эта статья является продолжением расширения конфигурации с помощью конвейера CI. Сначала я демонстрирую настройку конвейера, а затем его выполнение. Далее идет сама конфигурация CI.

Непрерывная интеграция (CI) просто означает, что изменения кода, которые фиксируются в центральном репозитории, создаются и тестируются автоматически. Популярной платформой с открытым исходным кодом для настройки CI-конвейеров является GitLab. В дополнение к центральному репозиторию Git, GitLab также предлагает настройку конвейеров CI/CD, отслеживание проблем и реестр контейнеров.

Условия, которые нужно знать

Прежде чем я углублюсь в эту область философии DevOps, я остановлюсь на некоторых общих терминах, встречающихся в этой статье и документации GitLab:

  • Непрерывная доставка (CD): автоматическая подготовка приложений с целью их развертывания.
  • Непрерывное развертывание (CD): автоматическая публикация программного обеспечения.
  • Конвейеры: компонент верхнего уровня для CI/CD, определяет этапы и задания.
  • Этапы: набор заданий, которые должны быть выполнены успешно.
  • Задания: определение задач (например, компиляция, выполнение модульного теста).
  • Исполнители: службы, которые фактически выполняют задания.

Настройка конвейера CI

Я буду повторно использовать примеры проектов из предыдущих статей, доступных на GitLab. Чтобы выполнить шаги, описанные в следующих главах, создайте ветвь примера проекта, нажав кнопку Разветвить, которая находится в правом верхнем углу:

Стефан Авенведде (CC BY-SA 4.)

Настройка бегуна

Чтобы понять, как все работает вместе, начните с самого начала, установив бегун в локальной системе.

Следуйте инструкциям по установке службы запуска GitLab для вашей системы. После установки вам необходимо зарегистрировать бегун.

1. На странице GitLab выберите проект и на левой панели перейдите к Настройки и выберите CI/CD.

Стефан Авенведде (CC BY-SA 4.0)

2. Разверните раздел «Спонсоры» и отключите параметр Общие бегунки (желтый маркер). Обратите внимание на токен и URL-адрес (зеленый маркер); они понадобятся нам на следующем этапе.

Стефан Авенведде (CC BY-SA 4.0)

3. Теперь откройте терминал и введите gitlab-runner Register. Команда вызывает сценарий, который запрашивает некоторый ввод. Вот ответы:

  • Экземпляр GitLab: https://gitlab.com/ (скриншот выше)
  • Регистрационный токен: выберите его в разделе Бегуны (скриншот выше).
  • Описание: Свободный выбор
  • Теги: Это необязательно. Вам не нужно указывать теги
  • Исполнитель: выберите здесь Shell.

Если вы захотите изменить конфигурацию позже, вы можете найти ее в разделе ~/.gitlab-runner/config.toml.

4. Теперь запустите бегун командой gitlab-runner run. Бегун теперь ждет работы. Теперь ваш бегун доступен в разделе Раннеры настроек проекта на GitLab:

Стефан Авенведде (CC BY-SA 4.0)

Выполнить конвейер

Как упоминалось ранее, конвейер — это набор заданий, выполняемых бегуном. Каждый коммит, отправленный в GitLab, генерирует конвейер, прикрепленный к этому коммиту. Если несколько коммитов объединены вместе, конвейер создается только для последнего коммита. Чтобы запустить конвейер в демонстрационных целях, зафиксируйте и отправьте изменение непосредственно через веб-редактор GitLab.

Для первого теста откройте README.md и добавьте дополнительную строку:

Стефан Авенведде (CC BY-SA 4.0)

Теперь зафиксируйте изменения.

Обратите внимание, что по умолчанию установлено значение Создать новую ветку. Для простоты выберите Применить к основной ветке.

Стефан Авенведде (CC BY-SA 4.0)

Через несколько секунд после фиксации вы должны заметить вывод в окне консоли, где выполняется программа GitLab:

Checking for jobs... received job=1975932998 repo_url=https://gitlab.com/hANSIc99/cpp_testing_sample.git runner=Z7MyQsA6

Job succeeded duration_s=3.866619798 job=1975932998 project=32818130 runner=Z7MyQsA6

В обзоре проекта в GitLab выберите на правой панели CI/CD --> Pipelines. Здесь вы можете найти список недавно выполненных конвейеров.

Стефан Авенведде (CC BY-SA 4.0)

Если вы выберете конвейер, вы получите подробный обзор, в котором вы сможете проверить, какое задание не выполнено (в случае сбоя конвейера), а также просмотреть результаты отдельных заданий.

Задание считается невыполненным, если было возвращено ненулевое значение. В следующем случае я просто вызвал команду bash exit 1 (строка 26), чтобы задание не удалось:

Стефан Авенведде (CC BY-SA 4.0)

Конфигурация CI

Конфигурации этапов, конвейеров и заданий выполняются в файле .gitlab-ci.yml в корне репозитория. Я рекомендую редактировать конфигурацию с помощью встроенного редактора Pipeline GitLab, поскольку он автоматически проверяет точность во время редактирования.

stages:
- build
- test

build:
  stage: build
  script:
    - cmake -B build -S .
    - cmake --build build --target Producer
  artifacts:
    paths:
      - build/Producer

RunGTest:
  stage: test
  script:
    - cmake -B build -S .
    - cmake --build build --target GeneratorTest
    - build/Generator/GeneratorTest

RunCTest:
  stage: test
  script:
    - cmake -B build -S .
    - cd build
    - ctest --output-on-failure -j6

В файле определены этапы сборка и тестирование. Далее он определяет три задания: build, RunGTest и RunCTest. Задание сборка назначается одноименному этапу, а остальные задания — этапу тестирование.

Команды в разделе script представляют собой обычные команды оболочки. Вы можете читать их так, как если бы вы вводили их построчно в оболочке.

Хочу отметить одну особенность: артефакты. В данном случае я определяю двоичный файл Producer как артефакт задания build. Артефакты загружаются на сервер GitLab и их можно скачать оттуда:

Стефан Авенведде (CC BY-SA 4.0)

По умолчанию задания на более поздних стадиях автоматически загружают все артефакты, созданные заданиями на более ранних стадиях.

Ссылка на gitlab-ci.yml доступна на docs.gitlab.com.

Заворачивать

Приведенный выше пример является элементарным, но он показывает общий принцип непрерывной интеграции. В приведенном выше разделе о настройке раннера я деактивировал общие бегуны, хотя в этом и есть сильная сторона GitLab. Вы можете создавать, тестировать и развертывать свое приложение в чистых контейнерных средах. В дополнение к свободно доступным раннерам, для которых GitLab предоставляет бесплатный ежемесячный контингент, вы также можете предоставить свои собственные автономные раннеры на основе контейнеров. Конечно, есть и более продвинутый способ: вы можете оркестровать контейнерные исполнители с помощью Kubernetes, что позволяет свободно масштабировать обработку конвейеров. Подробнее об этом можно прочитать на сайте about.gitlab.com.

Поскольку я использую Fedora, я должен отметить, что Podman пока не поддерживается в качестве контейнерного движка для запуска GitLab. Согласно выпуску gitlab-runner #27119, поддержка Podman уже есть в списке.

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

Статьи по данной тематике: