web-dev-qa-db-fra.com

Numéro de problème Jira dans le message de validation git

Dans notre entreprise, nous passons de svn à git. Pour le suivi des problèmes, nous utilisons JIRA d'Atlassian.

Maintenant, nous voulons faire en sorte que chaque message de validation contienne un numéro de problème (comme nous l'avons fait avec svn).

Nous avons trouvé le hook commit-msg que nous utilisons pour rejeter un commit s'il ne contient pas de numéro de problème.

JIRA utilise Fisheye pour scanner le dépôt git. Si un message de validation contient un numéro de problème, les modifications sont affichées sous ce problème.

Le problème est qu'un hook n'est pas copié lorsqu'un référentiel git est cloné. Les numéros de problème dans les messages de validation ne sont donc pas appliqués. Cela signifie que lorsqu'un nouveau commit est poussé en amont, Jira peut ne pas répertorier les modifications sous un problème.

La question est; utilisons-nous Git d'une manière ou d'une autre de manière incorrecte et existe-t-il un moyen d'imposer vraiment un numéro de problème dans le message de validation? Ou est-ce que quelqu'un a simplement un script/hook (autre que le hook commit-msg) qui accomplit cela?

githookpushjiraissue-tracking
29
meijuh

J'ai utilisé git-jira-hook et l'ai adapté à mes besoins, ce qui devrait également fonctionner pour vous. Pour vos besoins, supprimez simplement les parties où il se connecte à Jira pour vérifier si le numéro de problème jira regexé du message de validation est valide. Si vous n'aimez pas python (git-jira-hook est écrit en python) et préférez bash, vous devriez pouvoir adapter les exemples de scripts dans le répertoire .git/hooks de chaque dépôt à votre Besoins.

En ce qui concerne l'implémentation de quelque chose qui fonctionnera pour tout le monde, vous souhaitez utiliser git-jira-hook comme hook de mise à jour sur votre référentiel en amont. Cela bloquera les push qui contiennent des messages de validation qui n'ont pas de références de problème Jira appropriées. Comme il est plus pratique d'obtenir des commentaires sur les références de problème manquantes au moment de la validation (plutôt qu'au moment de la transmission), vous devrez demander à vos développeurs d'installer git-jira-hook comme leur crochet commit-msg. J'expliquerai plus tard comment cela peut être fait à l'échelle mondiale.

Voici comment j'ai résolu ce problème:

  1. Hook privé commit-msg: J'ai modifié git-jira-hook pour vérifier les références de problème jira dans la notation que nous utilisons. Ensuite, j'ai envoyé le crochet par e-mail avec des instructions à tout le monde expliquant comment installer le crochet globalement, comme expliqué dans this SO question . Si vous installez le crochet globalement, alors il sera utilisé dans tous les futurs clones, et peut être facilement appliqué à des dépôts déjà clonés en utilisant git init.

  2. Crochet de mise à jour du dépôt en amont: j'ai utilisé le script git-jira-hook déjà modifié et l'ai installé dans chacun de nos dépôts. Je n'ai pas pu faire fonctionner les bits d'authentification interactifs sur le dépôt en amont (lien symbolique), j'ai donc plutôt créé un utilisateur Jira à autorisations restreintes et codé en dur leur authentification dans le script.

15
Freerobots

Si vous utilisez npm, vous pouvez utiliser https://github.com/typicode/husky avec https://github.com/marionebl/commitlint

Créer un fichier: commitlint.config.js

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

et ajoutez la configuration du hook dans package.json

commit-msg: commitlint -E HUSKY_GIT_PARAMS

6
user2350849

Vous pouvez également avoir des hooks côté serveur, un hook de pré-réception ou quelque chose, mais ce n'est pas évident si vous êtes habitué à github.

À défaut, je pourrais envisager de fournir une option de construction `` install-hooks '' (comme tâche de râteau, tâche de création ou autre), bien que cela me fasse me sentir un peu `` sale '' car maintenant ma génération est liée au système de contrôle de version ...

1
Arafangion

Il existe un module complémentaire pour cela: Commit Policy Plugin for JIRA !

Il vérifie non seulement si la clé de problème JIRA est "formellement" incluse dans le message, mais vérifie également si le ou les problèmes correspondants correspondent à une requête JQL. En utilisant cela, vous avez une multitude de possibilités, pour autoriser la vérification uniquement par rapport à certains types de problèmes, des problèmes dans certains statuts, des problèmes dans le sprint Scrum actuel, des problèmes ciblant la prochaine version, etc.

enter image description here

En prime, il fonctionne à la fois avec votre système de contrôle de version d'origine ( Subversion ) et cible ( Git ), ce qui permet de contrôler votre travail même pendant la période de transition.

Vous pouvez installer le script de hook sur le dépôt béni et sur toutes les fourches. Malheureusement, les scripts de hook ne sont pas clonés lors du clonage d'un dépôt avec Git, mais nous étudions actuellement des solutions de contournement.

Documents complets: http://www.midori-global.com/products/jira-commit-policy-plugin/documentation/

Avertissement: il s'agit d'un module complémentaire commercial et pris en charge pour JIRA, et je suis un développeur qui y travaille.

0
Ferenc Kiss

Le hook Git n'est pas copié lorsqu'un référentiel est cloné. Nous vous recommandons d'utiliser husky . Cela peut aider à publier des hooks git pour tous ceux qui clones le référentiel.

Pour mandater git s'engager à inclure une référence jira id. J'ai configuré cela dans un dépôt - husky-jira-demo . J'espère que cela peut répondre à vos besoins.

0
Samar Panda

Si vous utilisez des hooks par défaut dans le dossier .git, les modifications que vous y apportez ne seront pas indexées, ce qui signifie simplement qu'elles ne peuvent pas être extraites ou clonées.

vous pouvez déplacer votre hook de message de validation dans un dossier différent nommé 'hooks' et le valider de manière à écraser les hooks par défaut de .git.

Nous affichons une boîte de message comme une erreur si la validation ne contient pas de numéro de problème afin que l'utilisateur puisse continuer s'il n'a pas besoin d'avoir un numéro de suivi des problèmes (fonctionne dans les cas de correctif/correctif)

0
Sumedh Tambe