Как убедиться, что файл был изменен в запросе на удаление - PullRequest
0 голосов
/ 24 мая 2018

Сначала просто краткое введение в настройку:

Итак, в нашей настройке мы используем gradle и артефакт для публикации новых сборок и получения зависимостей в сочетании с jenkins для конвейеров и git с bitbucket для управления исходным кодом.В нашей настройке любые команды «тянуть к хозяину» проходят через запрос на получение в bitbucket, который должен пройти через ворота, определенные в jenkinsfile, и просмотреть.После того, как они пройдут, пользователь может объединить запрос.

Поскольку у нас есть установка, в которой есть много репозиториев git, каждое из которых может быть опубликовано отдельно, крайне важно, чтобы пользователи не забывали корректно изменять семантическую версию, когда ониизвлеките их изменения в master (поскольку каждая сборка, которая выполняется на master, публикует выходные данные сборки в артефакте).Поэтому, чтобы люди не забыли обновить семантическую версию, я хотел бы либо проверить, что файл gradle.properties изменился по сравнению с той точкой, где была создана ветвь. Но поскольку мы используем мелкие клоны на нашем сервере jenkins, информации оэтот.Поэтому обычные команды "git diff" не будут работать.(Мой мерзавец не очень силен, но я пытался гуглить вокруг, и пока ничего не получалось).

Возможно, другим решением будет зацепка в битбакете, которая отвергает PR, который не имеет каких-либо изменений в семантике.версия.Но я еще не нашел такой плагин.

Третий вариант - это githook, который просто удаляет его при создании ветки, но я бы хотел, чтобы пользователь на 100% знал, что версия поднята, так какиногда очень важно, была ли увеличена основная, дополнительная версия или версия патча.(И, возможно, это не сработает, если люди создадут ветку в jira / bitbucket ...)

Есть идеи?

1 Ответ

0 голосов
/ 24 мая 2018

Не могу поверить, но у меня точно такая же настройка :) Самым простым решением для меня было то, что у меня есть задания, которые публикуются в aritifactory (этап публикации), но перед тем, как они это делают, они создают тег git (этап тегирования).на основе версии в gradle.properties.Теперь, если этот тег уже существует, нажать его не удастся.Допустим, у вас есть тег v1234, и вы делаете
git tag v1234 - будет работать
git push --tags - не удастся
Также я уведомляю bitbucket о неудачной сборке, и тогда люди могут увидеть, что это произошло, потому чтотег git уже существует, что означает, что они не обновили версию

...