Как артефакты передаются между job

Как я упоминал в прошлых постах, Job можно представить как функцию: есть входные и выходные данные. Существует два типа данных, которые могут быть как входными, так и выходными аргументами:

👉 Переменные окружения
👉 Артефакты

Как вы помните все Job исполняются Runner'ом. Поэтому перед началом исполнения Job, нужно эти данные передать в сам Runner.

Переменные окружения представляют собой HashMap на уровне всей операционной системы, к которым можно обратиться из любой программы. В контексте CI они могут использоваться, например, для хранения номера билда. В первой Job генерируется какое-то число, которое затем передается через переменные окружения в другие Job. Кроме того, CI-системы добавляют множество своих переменных, чтобы определить, на какой ветке выполняется Job, а также токены для API и другие данные.

Переменные окружения почти ничего не весят и передаются в Runner через CI-сервер, когда он получает задание. Здесь нет ничего интересного.

Артефакты уже куда более интереснее, так как артефактами могут быть любые файлы и папки, удовлетворящие ограничениям по размеру. Самый распространенный пример — это сборка. Одна Job собирает приложение, вторая Job деплоит его или отправляет в магазин приложений. Передать артефакт через CI так же просто, как с переменными окружения, уже не получится. Артефакты могут достигать гигабайтов, и часто одна Job создает артефакт, который нужен в нескольких других Job. Если гонять эти данные через CI-сервер, скорость его работы будет конкурировать с парализованной бабкой.

Следовательно, необходим третий компонент системы, который будет выполнять роль хранения артефактов. Этим компонентом является S3-совместимое хранилище. Job генерирует артефакт, затем все файлы упаковываются в архив и отправляются в S3. Отправленные файлы будут доступны только тем Job, у которых совпадает ID пайплайна. Это гарантирует, что в Job не попадет артефакт из другого пайплайна. Другие Job, которым нужен этот артефакт, просто скачивают его из S3 напрямую, минуя CI-сервер.

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