Как я могу заставить Hudson автоматически создавать и устанавливать артефакты выпуска, а не просто снимки? - PullRequest
Новая
       41

Как я могу заставить Hudson автоматически создавать и устанавливать артефакты выпуска, а не просто снимки?

3 голосов
/ 19 октября 2010

Я разрабатываю несколько проектов на своем ноутбуке и периодически нажимаю на github.Я установил частный сервер hudson в облаке, который опрашивает git-репозитории на наличие обновлений и, таким образом, выполняет сборки - пока что все хорошо.

К сожалению, когда я выполняю 'mvn release: prepare' на моемНоутбук, чтобы выполнить релиз (скажем, «1.5»), две происходящие фиксации (изменение 1.5-SNAPSHOT на 1.5, затем 1.5 на 1.6-SNAPSHOT) помещаются в мое git-репо, и Хадсон, очевидно, создает самую последнюю, т.е.1.6-SNAPSHOT - и полностью игнорирует релиз 1.5.

Это не имеет большого значения, но проекты зависят друг от друга, и я хотел бы объявить версии без снимков в моих poms.Однако, когда проект B зависит от версии 1.5 проекта A, его нигде не найти в локальном репозитории maven для пользователя hudson в окне Hudson - потому что он никогда не был собран - и поэтому сборка проекта B завершается неудачей.

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

Я просматривал плагины Hudson и, в частности, плагин M2 Release:

http://wiki.hudson -ci.org // display / HUDSON / M2 + Release +Плагин

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

Обновление : некоторые из моих базовых требований заставили меня переосмыслить то, чего я хочу достичьПриносим свои извинения за то, что не выразили их раньше:

  • Большинство проектов имеют открытый исходный код или в конечном итоге должны быть открыты, и я хотел бы, чтобы кто-нибудь смог git clone любой отдельный проект, оформить заказтег выпуска и выполните mvn install, не требуя никаких других репозиториев для зависимостей, кроме maven central.
  • Чтобы получить согласованные результаты (на моем ноутбуке, сервере hudson и проверках других людей), это очевидноуказывает на предпочтение объявления зависимостей без снимков в моих poms (по крайней мере, для версий выпуска).
  • Это привело меня к пути попытки заставить Хадсона «установить mvn» артефакты выпуска, когда они просвистывали мимо, так что позже проект сборки B в Гудзоне не потерпит неудачу, когда не сможет найти версию выпуска проекта A (откуда и возник этот вопрос)

Дополнительно:

  • Я пользуюсь замечательным oss хостингом sonotype, который требует подписи GPG - и я не хочу, чтобы мой ключ GPG хранился на любом харdware, я не могу держать в руке :) - поэтому вставлять его на сервер Hudson в облаке не вариант.
  • Мысленно, когда сервер Hudson делает выпуски, это немного чуждо мне - яна самом деле просто хочу это для КИ.

Ответы [ 3 ]

2 голосов
/ 20 октября 2010

Теперь вам нужно выполнить релиз.Цитирование Maven - Руководство по использованию плагина релиза :

Выполнение релиза

Плагин будет извлекать ревизии файлов, связанные с текущим релизом.Maven скомпилирует, протестирует и упакует версионный исходный код проекта в артефакт. Окончательный результат будет затем выпущен в соответствующий репозиторий maven .

Цель release:perform будет:

  1. Извлечь ревизии файлов с версией под новым именем тега.
  2. Выполнение жизненного цикла сборки maven на извлеченном экземпляре проекта.
  3. Развертывание версионных артефактов в соответствующих локальных и удаленных хранилищах .

Ссылки

0 голосов
/ 22 октября 2010

Я обновил свое описание проблемы, чтобы упомянуть мое предпочтение декларировать зависимости без снимков в моих poms (по крайней мере, для версий выпуска), чтобы получить согласованные результаты (на моем ноутбуке, сервере hudson и других людях). checkouts) - я действительно хочу, чтобы другие люди могли проверить мой код и начать с нуля искать неуловимые зависимости моментальных снимков.

Было желание использовать версии без снимков в моих зависимостях, что привело к этому вопросу - нормальное поведение Хадсона не облегчало использование версий «выпуска», по крайней мере, не дожидаясь, пока релиз-версия зависимости будет циклически изменена до Maven Central.

Однако я решил, что если я хочу быть верным своему основному требованию - чтобы люди могли легко извлекать и создавать мой код, - это то, что я должен сделать: то есть дождаться синхронизации maven central.

Я хочу придерживаться этого только для релизных сборок (в противном случае я бы никогда ничего не получил готово !), И поэтому буду радостно развиваться с использованием снэпшотов - вплоть до того момента, когда я на самом деле do хочу выпустить версию, после чего я хочу, чтобы все отделы были правильно доступны в maven central.

До недавнего времени я не знал ни о каком способе принудительного применения этого, но немного больше прибегнув к поиску, я обнаружил плагин «принудительного применения»:

http://maven.apache.org/enforcer/enforcer-rules/requireReleaseDeps.html

- с флагом 'onlyWhenRelease', установленным в true, похоже, что он должен полностью обеспечить выполнение того, что я хочу сделать.

В ответ на мой первоначальный заголовочный вопрос («Как я могу заставить Хадсона автоматически создавать и устанавливать артефакты выпуска, а не просто снимки?»), Мой ответ:

  1. Кажется, что нет никакого тривиального способа заставить Хадсона сделать это (без побочного эффекта Хадсона, также пытающегося сделать «релиз» при каждой проверке, которую он обнаруживает, что может потребовать дополнительной конфигурации «профиля», чтобы остановить фактическую обычные действия релиза, например подпись GPG)
  2. Не делай этого.
0 голосов
/ 21 октября 2010

Вы можете указать профили, которые определяют, будет ли сборка развернута локально или удаленно: 

<project>
    <profile>
        <id>local-deploy</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <distributionManagement>
            <repository>
                <id>local-repo</id>
                <name>My Local Repo</name>
                <url>file://my/local/repo/dir</url>
            </repository>
        </distributionManagement>
    </profile>
    <profile>
        <id>remote-deploy</id>
        <activation>
            <activeByDefault>false</activeByDefault>
            <property>
                <name>remote.repo.url</name>    
            </property>
        </activation>

        <distributionManagement>
            <repository>
                <id>remote-repo</id>
                <name>My Remote Repo</name>
                <url>${remote.repo.url}</url>
            </repository>
        </distributionManagement>
    </profile>
</project>

Затем вы можете безопасно запустить цель release:perform и, передав значение для remote.repo.url, у вас также есть возможность удаленного развертывания.

...