Вот проблема: всякий раз, когда Дженкинс регистрирует новую ревизию Subversion, она запускает другую сборку Дженкинса.Вы, вероятно, не хотите этого.Кроме того, вы не должны регистрировать в Subversion то, что генерируется сборкой.Это быстро приведет к тому, что ваш репозиторий вырастет за пределы вашего текущего размера диска, и вы получите тонну артефактов в вашем репозитории, которые никому не интересны. Вместо этого:
Используйте архивные возможности Jenkins длясохраните свои артефакты сборки.
Это делает их намного более заметными и их легче найти.Кроме того, вы можете автоматически заставить Дженкинса избавиться от них, когда они вам больше не нужны.Помните, что вы можете блокировать сборку Jenkins, чтобы предотвратить обнаружение артефактов, которые вы действительно хотите сохранить (например, бинарный файл фактического выпуска).
Кроме того, ваша другая машина может использовать wget
или curl
, чтобы извлечь их из репозитория Jenkins.
Если для другой работы Jenkins, требующей этихАртефакты - это еще одно задание Jenkins. Вы можете использовать этот плагин, чтобы скопировать артефакты из этого задания в другое и автоматически выполнить второе задание.Я делаю это, когда у меня есть тесты для запуска со сборкой, выполнение которой может занять более нескольких минут.
Пойдите изо всех сил и используйте Maven
Даже если вы не используете Maven какпроцесс сборки, это отличный способ для хранения и управления артефактами.Jenkins может хранить артефакты в Maven как часть процесса сборки, и вы можете использовать wget
, curl
или даже сам Maven для автоматического извлечения артефактов из хранилища.
Это немного сложнее, но это определенный стандартный метод, который не зависит от Jenkins.Это хорошо, если вы решите переехать из Дженкинс, чтобы сказать TeamCity.Вы не застряли в зависимости от запатентованного процесса в Jenkins.