Итак, погнали, что такое пайплайн и из чего состоит.

В разных CI системах эта сущность называется по-разному: пайплайн, build chain, workflow. Суть у всех одна, поэтому я буду использовать термин "пайплайн". Любой пайплайн состоит из трех базовых вещей:

👉 триггер – который запускает пайплайн
👉 job (он же Action, он же Build) – части пайплайна, в которых происходит работа, об этом позже
👉 связи между job – в какой последовательности запускать job, кто кого должен ждать

Триггер – отвечает за то, при каком событии стартует пайплайн. Разнообразие зависит от конкретной системы, но чаще всего триггеры привязаны к событиям в Git. CI система следит за изменениями в git и запускает пайплайны на разные события: пуш ветки, мерж ветки, пуш тега. Есть события на абстракции поверх git, например, создание мерж-реквеста. Помимо этого есть шедулинг (запуск в определенное время), ручной запуск по кнопке, запуск по API и всякие вебхуки, которые позволяют подключать сторонние системы.

Job – атомарная единица пайплайна, в которой и происходит работа. В 99% случаев это просто запуск какого-то скрипта в нужном окружении. Саму по себе Job можно представить как функцию. Есть данные на вход, есть данные на выход. Job может быть без сайд-эффектов, а может что-то изменять вовне, например, отправлять сборку в сторы или пушить докер-образ.

Связи между Job. Решил выделить в отдельный пункт, потому что это довольно важная часть, от этого зависит нагрузка на инфраструктуру. Связи позволяют задать зависимости между Job, указать, нужно ли скачивать артифакты от предыдущей Job и что делать, если предыдущая Job упала.

Если собрать все это вместе, то получаем, что сам по себе пайплайн — это просто коллекция job, которые среагировали на какой-то триггер, выстроились в нужный порядок и были запущены в едином контексте.