Первый job: три строки и зелёная галочка
Пишем минимальный .gitlab-ci.yml, пушим и смотрим, как GitLab сам поднимает контейнер и выполняет команду.
Файл, который запускает всё
CI в GitLab включается одним файлом в корне репозитория —
.gitlab-ci.yml. Никаких кнопок, никакой настройки сервера: положили файл,
запушили, GitLab нашёл его сам.
Создайте файл прямо в папке проекта:
hello:
script:
- echo "Hello, CI!"
Три строки, и это уже рабочий пайплайн. hello — имя job, любое на ваш
вкус. В script перечислены команды, которые выполнит раннер.
Пуш и что происходит дальше
git add .gitlab-ci.yml
git commit -m "add first pipeline"
git push
Дальше GitLab делает это сам:
- видит новый коммит и файл
.gitlab-ci.yml; - ставит пайплайн в очередь;
- свободный раннер берёт задачу, поднимает чистый контейнер Linux;
- клонирует туда ваш репозиторий;
- выполняет команды из
scriptпо порядку; - гасит контейнер и отдаёт статус.
Раннер — это машина, которая выполняет job. На gitlab.com есть общие раннеры, они включены по умолчанию, свои поднимать не нужно.
Смотрим результат
В проекте откройте Build -> Pipelines. Там строка с вашим коммитом
и статусом. Первые секунды это Pending (ждём свободный раннер), потом
Running, потом Passed.
Простой job такого размера отрабатывает секунд за 20, из которых сама
команда echo занимает миллисекунды. Остальное уходит на подъём
контейнера и клонирование репозитория.
Кликните по job, там лог целиком: как раннер выбрал образ, склонировал
код, выполнил echo "Hello, CI!" и завершился с Job succeeded.
Зелёный и красный
Статус job определяется кодом возврата последней команды: ноль означает успех, любое другое число — падение. Обычная логика shell, ничего специфичного для GitLab тут нет.
Проверьте сами: добавьте вторую команду, которая гарантированно упадёт.
hello:
script:
- echo "Hello, CI!"
- cat no-such-file.txt
Пайплайн станет красным, в логе будет No such file or directory и
ERROR: Job failed: exit code 1. Уберите лишнюю строку, запушьте снова, и
статус вернётся в зелёный.
Красный пайплайн означает, что CI работает. Он для того и нужен, чтобы падать раньше, чем сломанный код доедет до прода.
Если пайплайн не появился
Файл называется ровно .gitlab-ci.yml, с точкой в начале, и лежит в корне
репозитория. gitlab-ci.yml или .gitlab-ci.yaml GitLab не подхватит.
Долгий Pending обычно означает, что свободных раннеров нет или кончились
бесплатные минуты: Settings -> CI/CD -> Runners покажет, что
доступно проекту. А если аккаунт не прошёл проверку личности, job не висит,
а падает с сообщением Identity verification is required in order to run CI jobs.
YAML чувствителен к отступам. Проверить конфиг до пуша можно в Build -> Pipeline editor, он подсвечивает ошибки синтаксиса.
Что важно запомнить
.gitlab-ci.yml в корне репо — единственное, что нужно для запуска CI.
Job — это имя плюс список команд в script. Каждый job выполняется в
свежем контейнере, который умирает сразу после работы.
Статус берётся из кода возврата: ненулевой код красит пайплайн в красный.
Дальше разбиваем работу на стадии и выстраиваем их по порядку.
Прошли материал до конца? Отметьте урок пройденным.
Прогресс сохранён в этом браузере
Почистишь историю или откроешь с телефона, и отметки пропадут. Оставь почту, они переедут в аккаунт. Пароль придумывать не нужно.
Готово. теперь в аккаунте: прогресс виден с любого устройства. Мой прогресс