Практика GitLab CI/CD: собрать pipeline и разобраться, почему он сломался

Зелёный pipeline ещё не означает, что выпущено нужное приложение. Тест мог не запуститься, артефакт — оказаться от другой job, а ручной деплой — обогнать предыдущий. Ниже собраны разборы, из которых можно построить учебный pipeline: сначала надёжный запуск, затем передача результата между этапами, потом управляемый выпуск.

Окружение задания и повторяемый pipeline

Эти разборы помогают отделить проблему образа от конфигурации runner, проверить доступ к соседнему проекту и сделать повторный запуск предсказуемым.

• После timeout не сохранился отчёт: резервируем время GitLab Runner
• Параллельные jobs перезаписывают cache: выделяем одного писателя
• GIT_STRATEGY none оставил старые файлы: когда выбрать empty
• Job запускает справку вместо script: переопределяем entrypoint образа
• Pipeline изменился без коммита приложения: фиксируем версию include
• Опечатка в параметре CI-шаблона: проверяем inputs до запуска job
• CI_JOB_TOKEN получил 404 в другом проекте: проверяем allowlist
• GitLab CI не видит Redis: обращаемся к services по alias
• SSH из GitLab CI не доверяет серверу: передаём проверенный known_hosts

Как работать с подборкой

Возьмите отдельный репозиторий с коротким тестом и простой сборкой. Начните с двух jobs и добавляйте возможности по одной. Для каждой правки заранее сформулируйте ожидаемый результат: сколько pipelines появится, какая job запустится и какой файл она получит. Проверяйте это по реальному запуску.

Ниже — статьи с объяснениями и примерами. Практические эксперименты выполняются в вашем учебном окружении; это не встроенный автоматический экзамен.

1. Добиться запуска именно нужных jobs

Сначала отделите проблемы синтаксиса и runner от правил создания pipeline. Когда базовый запуск работает, переходите к переиспользованию конфигурации и особенностям shell.

• GitLab CI: job завис в pending — как проверить Runner и теги
• Команда с двоеточием сломала GitLab CI: различаем YAML и shell-кавычки
• GitLab CI запускает два pipeline на один push: разбираем workflow и rules
• GitLab CI потерял script после extends: как объединяется конфигурация
• after_script не видит export и cd: передаём состояние файлом
• GitLab CI не подключается к Docker daemon: DOCKER_HOST, TLS и executor

2. Передать результат следующему этапу

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

• Cache и artifacts в GitLab CI: как передать результат сборки следующему job
• GitLab не нашёл artifacts после cd: путь считается от каталога проекта
• Матрица GitLab собрала четыре варианта, а файлов два: разделяем пути artifacts
• Версия вычислена в build, но пропала в следующей job: отчёт dotenv
• Тесты красные, job зелёная: JUnit-отчёт и код завершения тестовой команды
• Ручной релиз не находит старые artifacts: срок хранения и неизменяемый релиз
• git describe видит тег локально, но не в CI: проверяем глубину истории

3. Управлять ветвлением и доступами

В монорепозитории не каждая правка требует полного выпуска. Но пропуск job меняет зависимости, а защищённые переменные доступны не во всех запусках. Отработайте эти случаи до того, как pipeline получит доступ к серверу.

• GitLab pipeline не создаётся из-за needs: условные jobs и optional
• Монорепозиторий в GitLab CI: запускаем проверки по изменённым каталогам
• Переменная GitLab CI пустая: protected, environment scope и тип File
• Дочерний pipeline упал, а родитель зелёный: strategy mirror и статус запуска

4. Не дать релизам мешать друг другу

Запустите два изменения подряд и посмотрите, что произойдёт со старым pipeline. Решите, какие этапы можно отменять, где допустим повтор и как сериализовать деплой в одно окружение.

• Два pipeline одновременно деплоят приложение: очередь через resource_group
• GitLab CI: отменяем устаревшие сборки и сохраняем нужный деплой
• Ручная job блокирует pipeline: when manual и allow_failure
• Retry скрывает красные тесты: повторяем только сбой runner

Соберите результат в одну рабочую процедуру

Итог упражнения — объяснимая цепочка от коммита до версии в окружении. По её журналу должно быть видно, какие тесты прошли, что собрано и кто разрешил выпуск. Если для ответа приходится вспоминать, на какую кнопку вы нажали вчера, зафиксируйте недостающие данные в самом процессе.

Продолжить обучение

Системно собрать такую цепочку поможет программа курса GitLab CI/CD: автоматизация сборки и деплоя. На странице курса — программа, условия доступа и покупки. Сопоставьте их со своей ближайшей рабочей задачей.

Если пока не хватает базы или нужен соседний инструмент, выберите другой маршрут в путеводителе по практике DevOps.