Numéro d'émission Jira dans le message de propagation git
nous déménageons de svn à git. Pour le suivi des émissions, nous utilisons JIRA d'Atlassian.
maintenant nous voulons faire en sorte que chaque message de propagation contienne un numéro de problème (comme nous l'avons fait avec svn).
nous avons trouvé le crochet commit-msg que nous utilisons pour rejeter une commit si elle ne contient pas de numéro de problème.
JIRA utilise Fisheye pour scanner le git repo. Si un message de propagation contient un numéro de problème, alors le les changements sont indiqués sous cette rubrique.
le problème est qu'un crochet n'est pas copié lorsqu'un dépôt git est cloné. Ainsi, les numéros d'émission dans les messages de propagation ne sont pas appliqués. Cela signifie que Lorsqu'un nouveau commit est poussé en amont, Jira ne peut pas lister les modifications dans un numéro.
la question Est: utilisons-nous Git d'une manière ou d'une autre de la mauvaise manière et y a-t-il un moyen d'appliquer réellement un numéro de problème dans le message de propagation? Ou est-ce quelque un ont simplement ont un script / hook (autre que le hook commit-msg) qui accomplit ceci?
4 réponses
j'ai utilisé git-jira-hook et l'ai modifié à mes besoins, qui devrait également fonctionner pour vous. Pour vos besoins, il suffit de supprimer les parties où il se connecte dans Jira pour vérifier si le numéro d'émission JIRA enregistré dans le message de propagation est valide. Si vous n'aimez pas python (git-jira-crochet est écrit en python) et préfèrent bash, vous devriez être en mesure d'adapter les scripts d'exemple dans chaque repo .git/hooks dir à vos besoins.
quant à la mise en œuvre de quelque chose qui fonctionne pour tout le monde, vous voulez utiliser git-jira-hook comme le crochet de "mise à jour" sur vos repos amont. Cela bloquera les push qui contiennent des messages de propagation qui ne contiennent pas de références de JIRA appropriées. Comme il est plus pratique d'obtenir des commentaires sur les références manquantes au moment de la propagation (plutôt qu'au moment de la poussée), vous aurez besoin d'amener vos développeurs à installer git-jira-hook comme leur crochet de propagation-msg. Je vous expliquerai plus tard comment cela peut être fait globalement.
Voici comment j'ai résolu ce problème:
-
Privé des pensions de s'engager à-msg crochet: J'ai modifié git-jira-hook pour vérifier les références de JIRA dans la notation que nous utilisons. Ensuite, j'ai envoyé le crochet avec des instructions à tout le monde expliquant comment installer le crochet globalement, comme est expliqué dans cette question SO . Si vous installez le crochet globalement, alors il sera utilisé dans tous les clones futurs, et peut être facilement appliqué à déjà cloné repos en utilisant git initialisation.
-
en Amont des pensions de mise à jour de crochet: J'ai utilisé le script git-jira-hook déjà modifié et je l'ai installé dans chacune de nos repos. Je n'ai pas pu faire fonctionner les bits d'authentification interactive sur le repo amont (symlinked it), donc j'ai créé un utilisateur JIRA de permissions restreintes et j'ai codé dur leur authentification dans le script.
vous pouvez avoir des crochets côté serveur ainsi, pré-receive-hook ou quelque chose, mais ce n'est pas évident si vous êtes habitué à github.
A défaut, je pourrais envisager de fournir une option de construction "install-hooks" (comme une tâche de râteau, faire une tâche, ou Autre), bien que cela me fasse me sentir un peu "sale" parce que maintenant ma construction est liée au système de contrôle de version...
il y a un add-on pour cela: Commit Policy Plugin for JIRA !
Il ne vérifie seulement si le JIRA question clé est "officiellement" inclus dans le message, mais vérifie également si le numéro correspondant(s) correspond à une JQL requête. En utilisant ceci, vous avez une multitude de possibilités, pour permettre de vérifier seulement contre certains types de problèmes, des problèmes dans un certain état, des problèmes dans le sprint de mêlée actuelle, des problèmes ciblant le prochain version et ainsi de suite.
en bonus, il fonctionne à la fois avec votre système de contrôle de version d'origine ( Subversion ) et de version cible ( Git ), ce qui rend votre travail contrôlé même pendant la période de transition.
vous pouvez installer le script de crochet à la repo bénie, et à toutes les fourches. Malheureusement, les scripts hook ne sont pas clonés lors du clonage un repo avec Git, mais nous sommes en train d'étudier des solutions de rechange pour cela.
Full docs: http://www.midori-global.com/products/jira-commit-policy-plugin/documentation /
clause de non-responsabilité: il s'agit d'un add-on commercial et supporté pour JIRA, et je suis un développeur qui travaille dessus.
si vous utilisez des crochets par défaut .le dossier git alors les changements que vous y faites ne seraient pas indexés ce qui signifie simplement qu'ils ne peuvent pas être vérifiés ou clonés.
vous pouvez déplacer votre crochet de message de propagation dans un dossier différent appelé 'hooks' et le propager pour qu'il écrase les crochets par défaut .Git.
nous montrons une boîte de message comme une erreur si commit ne contient pas un numéro de problème de sorte que l'utilisateur peut toujours aller de l'avant si il n'a pas besoin avoir un problème de tracker (travaux en cas de patch / correctif)