Стратегия для развертывания maven по заданию Дженкинса

У меня есть работа Jenkins, которая использует «чистые развертывания пакетов maven» для главной ветви git. Однако, в связи с связующей репо, не позволяя повторно развертывает, если задание Дженкинс работает второй раз без смены версии, она не будет выполнена с ожидаемой ошибкой 400 Bad Request:Стратегия для развертывания maven по заданию Дженкинса

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
    org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) 
    on project common-library: 
Failed to deploy artifacts: Could not transfer artifact 
    net.bacon.common:common-library:pom:1.2.13 from/to bacon-releases 
    (https://maven.bacon.com/nexus/content/repositories/releases): 
Failed to transfer file: 
    https://maven.bacon.com/nexus/content/repositories/releases/net/bacon/common/common-library/1.2.13/common-library-1.2.13.pom. 
Return code is: 400, ReasonPhrase:Bad Request.

Можно ли предложить другую стратегию, в результате чего цель развертывания может выполняться без сбоя в работе Jenkins?

источник

2013-04-22 Streetdaddy

Вы хотите развернуть снимок или версию выпуска? – Puce

вы не должны запускать * очистить развертывание пакета *, потому что во время фазы развертывания фаза пакета запускается во второй раз. Похоже, вы не заметили жизненного цикла. Это нужно только для запуска * чистого развертывания *. Если вы попытаетесь развернуть артефакт, который уже был развернут, вы не сможете запустить его второй раз. Для таких целей вы должны использовать -SNAPSHOT вместо релизов. – khmarbaise

@puce в этом случае это версия выпуска – Streetdaddy

то, что мы делаем, это автоматический сборщик снимков. то версия автоматически увеличивается.

для выпуска сборки, мы используем плагин релиза maven и вводим версию вручную. однако вы можете позволить плагину выпуска выполнить эту работу. он удалит сборку «-SNAPSHOT», развернет, а затем, для следующей версии версии, увеличит последнюю цифру и снова добавит «-SNAPSHOT».

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

источник

2013-04-22 13:51:18 rmalchow

+1 для развертывания снимков, а затем выполнить выпуск вручную с помощью Maven Release Plugin. Обратите внимание, что есть плагин Jenkins для поддержки Maven Release Plugin. – Puce

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

Есть веская причина для отказа от «перераспределения»: содержание выпущенной версии не должно меняться.

Если вы не можете избежать коммитов для одного и того же номера версии на главном, рассмотрите возможность изменения заданного задания jenkins для «чистой установки» (сохраняет артефакты только в локальном репозитории) и создайте новое задание с «чистым развертыванием», который запускается только вручную.

источник

2013-04-22 14:05:05

Это проблема для нашей группы.

Мы хотим, чтобы maven попытался выполнить ПАССИВНОЕ развертывание, поэтому, если развертывание существует в nexus, тогда оно будет приемлемо перемещаться с УСПЕХОМ УЖЕ РАЗРЕШЕНО, и если развертывание не существует в nexus, оно будет загружаться и развертываться с помощью SUCCESS.

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

Наше решение было обычным сценарием.

источник

2013-07-08 23:23:07 hansSolo

Мы применяем "двойного действия" решение:

Increment версия
Run МВН установить
Run тестирует
Если все прошло, мы бежим МВН развернуть

Таким образом, мы не пытаемся развернуть bef Мы знаем, что все прошло, и у нас есть уникальная версия, развернутая каждый раз.

Надеюсь, это поможет.

источник

2013-07-09 06:24:40

Вы нашли способ запустить тесты с ваших установленных банок с помощью Jenkins? – JBCP

Мы не используем установленные банки непосредственно. Мы собираем их в войнах, а затем в RPM, которые мы устанавливаем на выделенный сервер. Отвечает ли это на ваш вопрос? –

Вы можете использовать концепцию кандидата на выпуск. Когда вы начинаете выпуск, вы добавляете -RC1 в версию (например, 1.1.0-RC1).

При следующем перераспределении вы увеличиваете число RC. Когда выпуск завершен и вы хотите создать новый TAG, вы удаляете только RC для версии. перед созданием TAG

источник

2017-10-04 08:26:19

Стратегия для развертывания maven по заданию Дженкинса

ответ

Смежные вопросы