Job запускает справку вместо script: переопределяем entrypoint образа

Для проверки конфигурации выбрали готовый Docker-образ нужной утилиты. Локально docker run с этим образом печатает результат команды. В GitLab CI та же job выводит справку либо ошибку про неизвестный аргумент sh, хотя script содержит корректные shell-команды. Образ оказался удобным для прямого запуска CLI, но его ENTRYPOINT мешает исполнению задания runner.

Контейнер job — среда, в которой runner должен запустить подготовленный скрипт. А образ инструмента может заранее назначить основной исполняемый файл. Тогда аргументы, предназначенные оболочке, попадают в CLI. Добавлять кавычки вокруг script бессмысленно: ошибка находится до выполнения строк задания.

Отделить оболочку от инструмента

Для Docker executor entrypoint можно явно переопределить в описании image. Ниже пример с образом Python, где мы специально показываем форму настройки. В реальном проекте она нужна прежде всего образам с мешающим ENTRYPOINT.

check:
  image:
    name: python:3.12-slim
    entrypoint: [""]
  script:
    - python --version
    - python -m compileall src

После сброса entrypoint runner должен найти в образе подходящую оболочку и необходимые служебные команды. Минимальный образ, содержащий единственный статический бинарник, от этого не превращается в полноценную CI-среду. Для него лучше собрать отдельный образ задания с shell и инструментом либо вызывать утилиту из подходящей базовой среды.

Перед изменением посмотрите метаданные образа: docker image inspect покажет Entrypoint и Cmd. Сопоставьте их с поведением docker run без аргументов и с явными аргументами. Так становится видно, какие части команды являются поведением образа, а какие добавляет runner. Заодно можно обнаружить, что выбран другой тег, чем у локального запуска.

Проверить реальное выполнение script

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

Не добавляйте отключение entrypoint в глобальный default без разбора. В одном образе он только запускает CLI, в другом готовит окружение, сертификаты или пользователя. Если подготовка нужна, перенесите необходимые действия в понятный CI-образ и сохраните воспроизводимость. Иначе после исправления оболочки можно получить более скрытый сбой зависимостей.

Для команды полезно описать контракт образа задания: какая shell доступна, где находится инструмент и как задаётся рабочий каталог. Этот небольшой набор фактов делает переход между локальным контейнером и CI предсказуемым и уменьшает зависимость pipeline от особенностей чужого образа.

Продолжить практику

Исправление одной job полезно закрепить в полном процессе выпуска. В программе курса «GitLab CI/CD: автоматизация сборки и деплоя» — pipeline учебного приложения с проверками, тестами, сборкой Docker-образа, registry и staging. Отдельно разбираются runners, секреты, нестабильные запуски и возврат к предыдущему образу. Такой проект помогает увидеть, как решение внутри одной job влияет на выпуск версии и дальнейший откат.

Посмотреть программу курса

Источник: официальная документация.

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