Подтвердить что ты не робот

Архив артефактов в Дженкинсе

Может ли кто-нибудь объяснить мне идею артефактов в процессе сборки?

У меня есть каталог рабочей области, где я проверяю код для компиляции и запуска скриптов ant и т.д. В конце, в моем случае, я получаю файл jar, который готов к установке. Это считается артефактом?

Где я должен сообщить своей сборке script, чтобы поместить файл jar? В каталоге рабочей области? Мой файл jar получает уникальное имя файла в зависимости от таких переменных, как BUILD_ID и т.д., Как я могу рассказать Jenkins о том, какой файл jar выбрать?

EDIT: Хорошо, поэтому я попытался сделать что-то вроде этого:

enter image description here

Путь еще не существует в моей рабочей области, потому что предполагается, что он создаст конструкцию script, и, конечно, файлы .jar и .properties отсутствуют, потому что они еще не созданы. Почему это дает мне ошибку? Кажется, что я что-то пропустил.

Кроме того, Дженкинс удаляет артефакты после каждой сборки (а не архивные артефакты, я знаю, что могу сказать, чтобы удалить их)? В противном случае он будет довольно быстро засорять жесткий диск.

4b9b3361

Ответ 1

Ваше понимание верное, артефакт в смысле Дженкинса является результатом сборки - предполагаемого вывода процесса сборки.

Общим соглашением является поместить результат сборки в каталог build, target или bin.

Архиватор Jenkins может использовать globs (target/*.jar), чтобы легко подобрать правильный файл, даже если у вас есть уникальное имя для сборки.

Ответ 2

Артефакт может быть любым результатом вашего процесса сборки. Важно то, что неважно, на каком клиенте он был построен, он будет перенесен из рабочей области обратно на главный (сервер) и сохранен там со ссылкой на сборку. Преимущество состоит в том, что оно стандартизировано таким образом, вам нужно только настроить резервное копирование на своем хозяине и что все артефакты доступны через веб-интерфейс, даже если все клиенты сборки находятся в автономном режиме.

В качестве имени артефакта можно определить регулярное выражение. В моем случае я закрепил все файлы, которые я хотел сохранить в одном файле с постоянным именем во время сборки.

Ответ 3

Кроме того, Дженкинс удаляет артефакты после каждой сборки? (а не архивные артефакты, я знаю, что могу сказать, чтобы удалить их)

Нет, Хадсон/Дженкинс сам по себе не очищает рабочее пространство после сборки. У вас могут быть действия в процессе сборки, которые стирают, перезаписывают или перемещают артефакты сборки там, где вы их оставили. В конфигурации заданий есть опция "Расширенные параметры проекта" (которая должна быть расширена), которая называется "Очистить рабочее пространство перед сборкой", которая уничтожит рабочее пространство в начале новой сборки.

Ответ 4

В Jenkins 2.60.3 есть способ удалить артефакты сборки (а не архивные артефакты), чтобы сохранить пространство на жестком диске на машине сборки. В разделе "Общие" установите флажок "Отменить старые сборки" со стратегией "Вращение журнала", а затем перейдите в его дополнительные параметры. Появятся еще два параметра, связанных с сохранением артефактов сборки для задания на основе количества дней или сборок.

Настройки, которые работают для меня, состоят в том, чтобы ввести 1 для "Максимальное количество строчек для хранения артефактов", а затем выполнить пост-сборку для архивирования артефактов. Таким образом, все артефакты из всех сборников будут заархивированы, вся информация из сборников будет сохранена, но только последняя сборка будет содержать свои собственные артефакты.

Отменить старые варианты сборки