DEV_EASY_NOTES Telegram 445
Как артефакты передаются между 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-сервера.
🔥271🥰1😁1



tgoop.com/dev_easy_notes/445
Create:
Last Update:

Как артефакты передаются между 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-сервера.

BY Dev Easy Notes




Share with your friend now:
tgoop.com/dev_easy_notes/445

View MORE
Open in Telegram


Telegram News

Date: |

"Doxxing content is forbidden on Telegram and our moderators routinely remove such content from around the world," said a spokesman for the messaging app, Remi Vaughn. Those being doxxed include outgoing Chief Executive Carrie Lam Cheng Yuet-ngor, Chung and police assistant commissioner Joe Chan Tung, who heads police's cyber security and technology crime bureau. Matt Hussey, editorial director of NEAR Protocol (and former editor-in-chief of Decrypt) responded to the news of the Telegram group with “#meIRL.” During a meeting with the president of the Supreme Electoral Court (TSE) on June 6, Telegram's Vice President Ilya Perekopsky announced the initiatives. According to the executive, Brazil is the first country in the world where Telegram is introducing the features, which could be expanded to other countries facing threats to democracy through the dissemination of false content.
from us


Telegram Dev Easy Notes
FROM American