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

Artifactory + Jenkins: публикация в репозитории maven из сборки фристайла

У меня есть фристайл Jenkins, основанный на проекте Scala с использованием SBT. Я пытаюсь использовать плагин Jenkins Artifactory, чтобы опубликовать полученные артефакты в репозитории Artifactory, в частности, на сайте artifactoryonline.com. Тем не менее, я изо всех сил стараюсь найти разумную конфигурацию. Я склонен подозревать, что там что-то не хватает, но я нахожусь на своем конце, ни одна из документации, которую я нашел, по-видимому, не затрагивает этот прецедент, но я устал исходный код плагина Artifactory. Любая помощь вообще оценивается.

Сценарий следующий. Я бы хотел:

  • создайте проект Jenkins в свободном стиле, используя SBT, независимо от номера версии, так что текущая версия проекта (как закодирована в артефактах pom/ivy) является неявной и автоматической.
  • опубликуйте артефакты и создайте информацию в артефактивный репозиторий, настроенный в Jenkins (не настроенный в build.sbt в моем SCM)

Ниже приведены подходы, которые я пробовал.

Подход 1: Интеллектуальная интеграция Free-style + Generic Artifactory

Первый подход состоял в том, чтобы использовать сборку фристайла, а затем использовать интеграцию Generic-Artifactory. Для "Опубликованных артефактов" я установил его в

мишень/scala -2,11/* = > com.mycompany/мой-module_2.11

Сборка завершается успешно, файлы jar и sources-jar и javadoc-jar и ivy и POM файлы все сгенерированы в этом каталоге. Однако публикация не удалась, 209 Conflict. Журналу Artifactory не нравится целевой путь:

Отправка кода ошибки HTTP 409: Целевой путь развертывания 'com/mycompany/my-module_2.11/my-module_2.11-1.0.6.pom' не соответствует префиксу ожидаемого пути POM 'com/mycompany/my -module_2.11/1.0.6. Проверьте правильность своего содержимого POM и убедитесь, что исходный путь является допустимым корневым корнем Maven.

Я могу удалить ошибку 209, не используя стандартную траекторию maven-2 (которая, помимо прочего, требует отключения проверки целостности POM для этого репо), что предполагает, что мне придется обновлять всю конфигурацию нисходящего потока до иметь возможность работать с этим репо.

Я могу обновить параметр целевого пути для плагина, чтобы включить номер версии:

мишень/scala -2,11/* = > com.mycompany/мой-module_2.11/1.0.6

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

Подход 2: Free-style + Artifactory Maven

В этом случае я придерживался сборки SBT в свободном стиле. В разделе "Среда сборки" я выбрал "Maven3-Artifactory Integration". Я настроил плагин против моего глобального артефактивного хранилища, отметьте "Развернуть артефакты в Artifactory" и установите "Включить шаблоны" в

мишень/scala -2,11/*

Я запустил сборку, которая сгенерировала артефакты (включая файлы POM и ivy.xml в каталоге target/ scala -2.11), но ничего не происходило в отношении развертывания артефактов. В журнале Artifactory ничего не было, никаких новых сборок и ничего в консольном выпуске или журналах Jenkins, чтобы указать, что он когда-либо пытался развернуть артефакты в моем репозитории.

Подход 3: Free-style + Artifactory Ivy

В этом случае я придерживался сборки в свободном стиле, но в разделе "Среда сборки" я выбираю "Ant/Ivy-Artifactory Integration". Я выбрал глобально настроенный репозиторий Artifactory, отметьте "Опубликовать артефакты в Artifactory" и "Использовать совместимые шаблоны Maven". Я настроил свой проект SBT на "publishLocal" (в соответствии с инструкциями плагина), и я установил следующие пути снимок экрана конфигурации плюща. Проект был построен, и артефакты были развернуты на ~/.ivy2/local, но, видимо, не было перехвата плагином, и ничто не было перенесено на мое настроенное репетирование Artifactory (может быть, этот плагин несовместим со свободным стилем?)

Я модифицировал SBT-сборку, чтобы сделать "публиковать" вместо "publishLocal", надеясь, что плагин запустит и перехватит публикацию Ivy, но поскольку мой build.sbt не настроен с целью публикации в репозитории, я, естественно, возникла ошибка: "Репозиторий для публикации не указан".

Подход 4: сборка Dummy Maven

Следующий подход: пропустить общий, пройти полный maven. Я настраиваю новую сборку в Jenkins, проект Maven. Он имеет шаг предварительной сборки, который запускает мою сборку SBT, создавая артефакт pom вместе с двоичными и исходными банками. Затем я настраиваю шаг Build для использования POM, сгенерированного моей сборкой SBT. К сожалению, параметр "Root POM" плагина jenkins/maven не принимает подстановочный знак, поэтому единственный способ, которым я мог его обработать, - указать полный путь (версия):

мишень/scala -2,11/мой-resource_2.11-1.0.6.pom

Итак, это несчастливое и несостоятельное, поскольку я не хочу обновлять свою сборку Jenkins каждый раз, когда я увеличиваю номер версии. Тем не менее, я хотел посмотреть, будет ли этот подход работать, поэтому я настаивал. Я добавил шаг после сборки "Развертывание артефактов в Artifactory" против моего настроенного в мире Artifactory. С целями maven "помогите: помогите", ничего не толкнулось, поэтому не было ничего для перехватчика maven, чтобы перехватить и протолкнуть к моему искусству (что мое понимание того, как это работает, так или иначе). Поэтому я снова попробовал, заменив цели maven на этапе сборки "deploy". На этот раз перехватчик подталкивал большинство (всех?) Моих зависимостей к моему серверу Artifactory. Однако после нажатия всех зависимостей, похоже, не удалось скомпилировать мой проект "maven". Я больше не смотрел на это, но я предполагаю, что это связано с тем, что сгенерированный файл POM не указывает никаких инструкций сборки.

Заключение

Еще раз, любая помощь приветствуется. Похоже, что это должно быть довольно распространенным случаем, и в документации для плагина Artifactory явно указано, что поддерживается развертывание free-style build + Maven, но я, очевидно, что-то не вижу. Любая помощь очень ценится! Спасибо.

4b9b3361

Ответ 1

Это отличный вопрос!

Переход с "Подходом 1" - это путь. Если вы не хотите включать версию в путь, это делает путь не-maven совместимым, что может быть хорошо, но вам нужно настроить репо (как вы знаете и сделали). И да, решение в комментарии также является правильным трюком.