Jenkins: автоматическая проверка версии Maven-Release с использованием модульных тестов

Я пытаюсь настроить Jenkins-Job для выпуска Java-проекта с помощью подключаемого модуля Maven-Release-Plugin.
Я хочу убедиться, что основная версия, которую я использую, чтобы пометить выпуск как несовместимый с более ранним основным -Версия, меняется, если текущий Релиз несовместим с предыдущим.

Пример:

Последним выпуском была версия 1.9.5, которая содержала класс с именем Foo.
В текущем выпуске этот класс был удален.< br> Пользователь указывает текущую версию выпуска 1.9.6 и запускает Jenkins-Job.

Релиз должен сообщить пользователю, что текущая основная версия, как ожидается, будет 2, а не 1, поскольку API стал несовместимым.

Я подумал об использовании модульных тестов предыдущего выпуска для тестирования кода текущего выпуска. Если какой-либо API стал несовместимым, модульные тесты предыдущего выпуска должны завершиться ошибкой во время компиляции или тестирования (при условии, что для этого кода существует модульный тест).

Мой подход требовал бы держать тесты в отдельном проекте и проверять две версии из моей VCS.

Знаете ли вы о каком-либо Jenkins-Plugin, который может помочь в этом, или у вас есть какие-либо другие идеи о том, как проверить, не стал ли API несовместимым между двумя основными версиями?


jenkins java release unit-testing maven
person Marc-Christian Schulze    schedule 12.04.2012    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Поскольку у меня нет никакого понимания вашего API, поэтому я не могу предложить ничего, связанного с проверкой совместимости вашего API.

Что касается Jenkins/Maven, я бы посоветовал вам запустить фактическую сборку релиза как последующее задание задания ваших тестов, используя параметр действий после сборки, который называется «Запустить параметризованную сборку в других проектах».

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

person Community    schedule 12.04.2012

arrow_upward
1
arrow_downward

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

Ваша идея разделить модульные тесты на другой проект — хорошая. Просто запустите тесты предыдущего выпуска для версии -SNAPSHOT, которую вы предлагаете выпустить. Если пройдут, то ладно. В противном случае увеличьте основной номер версии.

person artbristol    schedule 12.04.2012
comment
Я думаю о следующих шагах для выполнения выпуска: - Извлечь новую копию VCS - Собрать текущий код и запустить модульные тесты - Извлечь модульные тесты предыдущего выпуска - Запустить предыдущие модульные тесты - Пометить VCS правильной версией - Начать выпуск и обновить текущую версию до следующей версии моментального снимка. Не было бы проще, если бы у нас было одно задание/инструмент, которому мы даем только текущую и следующую версии выпуска? - person Marc-Christian Schulze; 13.04.2012
comment
Да, наверное, проще было бы это сделать с помощью инструмента. Возможно, вы могли бы использовать mojo.codehaus.org/versions -maven-plugin/ в сочетании с модульными тестами старой версии? - person artbristol; 13.04.2012