Может кто-нибудь объяснить мне идею артефактов в процессе сборки?
У меня есть каталог рабочей области, где я извлекаю код для компиляции и запуска своих скриптов ant и т. Д. В конце, в моем случае, я получаю файл jar, который готов к установке. Это считается артефактом?
Где я должен указать сценарию сборки файл jar? В каталоге рабочей области? Мой jar-файл получает уникальное имя файла в зависимости от таких переменных, как BUILD_IDи то, как я могу сказать Jenkins, какой jar-файл выбрать?
РЕДАКТИРОВАТЬ: Хорошо, поэтому я попытался сделать что-то вроде этого:
Путь еще не существует в моем рабочем пространстве, так как сценарий сборки предполагается создать его, и, конечно же , .jarи .propertiesфайлы не там , потому что они еще не были сформированы еще. Почему это дает мне ошибку тогда? Похоже, я что-то упустил.
Кроме того, Дженкинс удаляет артефакты после каждой сборки (не архивные артефакты, я знаю, что могу сказать, чтобы удалить их)? В противном случае он довольно быстро засорит жесткий диск.
Ответы:
Ваше понимание верно, артефакт в смысле Дженкинса - это результат сборки - предполагаемый результат процесса сборки.
Общая конвенция является положить результат сборки в
build,targetилиbinкаталог.Архиватор Jenkins может использовать globs (
target/*.jar), чтобы легко подобрать нужный файл, даже если у вас есть уникальное имя для каждой сборки.источник
sh 'mvn clean package'Артефакт может быть любым результатом вашего процесса сборки. Важно то, что неважно, на каком клиенте он был построен, он будет перенесен из рабочей области обратно на мастер (сервер) и сохранен там со ссылкой на сборку. Преимущество состоит в том, что он версионизируется таким образом, вам нужно только настроить резервное копирование на своем главном сервере и что все артефакты доступны через веб-интерфейс, даже если все клиенты сборки отключены.
В качестве имени артефакта можно определить регулярное выражение. В моем случае я заархивировал все файлы, которые хотел сохранить, в один файл с постоянным именем во время сборки.
источник
Нет, Hudson / Jenkins сам по себе не очищает рабочую область после сборки. У вас могут быть действия в процессе сборки, которые стирают, перезаписывают или перемещают артефакты сборки с того места, где вы их оставили. В конфигурации задания в расширенных параметрах проекта (который необходимо развернуть) есть опция под названием «Очистить рабочее пространство перед сборкой», которая стирает рабочую область в начале новой сборки.
источник
В Jenkins 2.60.3 есть способ удалить артефакты сборки (не заархивированные артефакты), чтобы сэкономить место на жестком диске на машине сборки. В разделе «Общие» установите флажок «Отменить старые сборки» со стратегией «Ротация журналов», а затем перейдите в ее дополнительные параметры. Появятся еще две опции, связанные с хранением артефактов сборки для задания в зависимости от количества дней или сборок.
Мне подходят настройки: ввести 1 в поле «Максимальное количество сборок для хранения с артефактами», а затем выполнить действие после сборки для архивации артефактов. Таким образом, все артефакты из всех сборок будут заархивированы, вся информация из сборок будет сохранена, но только последняя сборка сохранит свои собственные артефакты.
Отменить старые варианты сборки
источник