Номер выпуска Jira в сообщении git commit - программирование

Номер выпуска Jira в сообщении git commit

В нашей компании мы переходим от svn до git. Для отслеживания проблем мы используем JIRA от Atlassian.

Теперь мы хотим обеспечить, чтобы каждое сообщение фиксации содержало номер проблемы (как и с svn).

Мы нашли крюк commit-msg, который мы используем для отклонения фиксации, если он не содержит номер проблемы.

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

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

Возникает вопрос: мы используем git как-то не так, и есть ли способ действительно ввести номер проблемы в сообщение фиксации? Или у кого-то просто есть script/hook (кроме крюка commit-msg), который это выполняет?

4b9b3361

Ответ 1

Я использовал git-jira-hook и изменил его на мои нужды, что также должно сработать для вас. Для ваших нужд просто удалите части, в которые он входит в Jira, чтобы проверить, действительно ли номер проблемы jira, повторно выраженный из сообщения фиксации. Если вам не нравится python (git -jira-hook написан на python) и предпочитает bash, вы должны иметь возможность адаптировать пример скриптов в каждом репо .git/hooks dir в соответствии с вашими потребностями.

Что касается реализации чего-то, что будет работать для всех, вы хотите использовать git -jira-hook в качестве "обновления" в ваших восходящих репозиториях. Это будет блокировать нажатия, содержащие сообщения фиксации, которые не имеют надлежащих ссылок на проблему с jira. Поскольку удобнее получать обратную связь о недостающих ссылках на момент фиксации (а не в момент нажатия), вам нужно заставить своих разработчиков установить git -jira-hook в качестве своего фиксатора-msg. Я объясню позже, как это можно сделать во всем мире.

Вот как я решил эту проблему:

  • Частный вызов repo commit-msg: Я изменил git -jira-hook, чтобы проверить ссылки на jira в обозначениях, которые мы используем. Затем я отправил по электронной почте крючок с инструкциями всем, объясняющим, как установить глобальный крючок, как объясняется в этом вопросе SO. Если вы установите глобальный ключ, он будет использоваться во всех будущих клонов и может быть легко применен к уже клонированным репозиториям с помощью git init.

  • Крюк обновления верхнего уровня обновления: Я использовал уже измененный git -jira-hook script и установил его в каждом из наших репозиториев. Я не мог получить биты интерактивной проверки, работающие над восходящим репо (символически связанный с ним), поэтому вместо этого я создал ограниченный доступ к пользователю Jira и жестко закодировал их аутентификацию в script.

Ответ 2

У вас также могут быть крючки на стороне сервера, pre-receive-hook или что-то еще, но это не очевидно, если вы привыкли к github.

В противном случае я мог бы подумать о том, чтобы создать вариант сборки "установочных крючков" (как задача рейка, сделать задачу или что-то еще), хотя это заставит меня почувствовать себя немного "грязным", потому что теперь моя сборка привязана к система контроля версий...

Ответ 3

Для этого есть надстройка: Плагин для политик для JIRA!

Он не только проверяет, является ли ключ сообщения JIRA "формально" включенным в сообщение, но также проверяет, соответствует ли соответствующая проблема запросу JQL-запроса. Используя это, у вас есть множество возможностей, позволяющих проверять только определенные типы проблем, проблемы в определенных статусах, проблемы в текущем спринте Scrum, проблемы с таргетингом на следующую версию и т.д.

введите описание изображения здесь

В качестве бонуса он работает как с вашим оригиналом (Subversion), так и системой контроля целевой версии (Git), что позволяет контролировать работу даже в течение переходного периода.

Вы можете установить hook script на благословенное репо и на любые вилки. К сожалению, скрипты hook не клонируются при клонировании репо с помощью Git, но мы в настоящее время изучаем обходные пути для этого.

Полные документы: http://www.midori-global.com/products/jira-commit-policy-plugin/documentation/

Отказ от ответственности: это коммерческое и поддерживаемое дополнение для JIRA, и я разработчик, работающий над ним.

Ответ 4

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

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

Мы показываем окно сообщения как ошибку, если commit не содержит номер проблемы, поэтому пользователь может продолжать работу, если ему не нужно иметь номер отслеживания проблем (работает в случае исправления/исправления)

Ответ 5

Если вы используете npm, вы можете использовать https://github.com/typicode/husky с https://github.com/marionebl/commitlint.

Создать файл: commitlint.config.js

module.exports = {
rules: {
    'references-empty': [2, 'never']
},
parserPreset: {
    parserOpts: {
        issuePrefixes: ['REF-']
    }
}};

и добавьте конфиг для хука в package.json

commit-msg: commitlint -E HUSKY_GIT_PARAMS