Je sais qu'il y a peu de plugins dans Bitbucket comme YACC, etc. que vous pouvez installer directement dans Bitbucket et qui deviennent disponibles pour les référentiels pour activer le hook de validation de pré-réception de jira. Y a-t-il quelque chose de similaire pour Github. Tout ce que je regarde, c'est quelle est la meilleure et la plus faisable solution pour activer une sorte de hook dans Github qui impose que tout commit effectué ait besoin d'une clé de problème jira valide. Ce serait encore mieux s'il y en avait un qui fasse la même chose pour la création de branche mais pas quelque chose d'important pour moi pour le moment.
Veuillez nous aider avec les étapes à suivre pour l'activer dans Github Enterprise.
4 Réponses :
Ce n'est pas possible avec Github.
Seul Github Enterprise prend en charge les hooks de pré-réception
et propose même un exemple d'application de problème JIRA dans les messages de validation - https://github.com/github/platform-samples/blob/master/pre-receive- hooks / require-jira-issue.sh
Vous pouvez également demander aux membres de votre équipe de configurer des hooks locaux pre-push
ou pre-commit
qui feront l'application.
Merci! J'ai d'abord essayé cela sur mon local en créant un fichier commit-msg.sh qui contient ce script et je l'ai enregistré sous par le dossier git repo / .git / hooks. Mais les commits fonctionnent localement comme avant, sans valider aucune expression régulière jira. Y a-t-il un moyen de faire respecter cela?
@Ashley Assurez-vous que votre fichier pre-commit
est exécutable.
Cette fonctionnalité est disponible en utilisant une solution centralisée pour les git-hooks côté serveur comme Datree.io < / a>. Il a des règles intégrées telles que:
Clause de non-responsabilité: je suis l'un des fondateurs de Datrees
Si vous avez configuré CI pour effectuer des vérifications sur une branche, alors j'ai fait un pipeline de branche comme ci-dessous pour y parvenir:
- npm ci - npm run lint - npm test # == Check that all commits since the base branch (dev) contain ACME- for ticket reference == # Fetch the merge base for our project - git fetch origin dev:dev - > echo "-- Checking ACME- prefix on commits --" && [[ `git log --oneline dev.. | grep -v 'ACME-' | wc -l` -eq 0 ]] && echo "Passed" || (echo "Failed for the following commits:" && git log --oneline dev.. | grep -v 'ACME-' && [[ 0 -eq 1 ]])
Naturellement, vous pouvez éviter le | | && gymnastics si vous extrayez ceci dans un fichier de script shell.
Si vous voulez dire GitHub Enterprise , vous pouvez vérifier les détails de la validation par rapport aux informations Jira avec outils similaires que vous avez déjà mentionnés du côté Jira .
Dans le cas de la version hébergée de GitHub, votre choix serait les hooks locaux, comme cela a déjà été mentionné. (Le plus efficace est d'ailleurs d'utiliser à la fois des hooks côté serveur et locaux) En cas de doute sur la façon de construire et d'installer votre script de hook local cet outil a un" assistant " qui vous guide à travers certaines étapes et crache le script à la fin.
Peut-être ne répond pas directement à votre besoin spécifique, mais c'est assez similaire la question a été publiée récemment. Au cas où cela pourrait être utile.
Merci! J'ai d'abord essayé cela sur mon local en créant un fichier commit-msg.sh qui contient ce script et je l'ai enregistré sous par le dossier git repo / .git / hooks. Mais les commits fonctionnent localement comme avant, sans valider aucune expression régulière jira. Y a-t-il un moyen de faire respecter cela? -
C'est en effet une solution locale, et dans mon cas, la seule «application» a été de communiquer et de s'organiser au sein de notre équipe. Pour rappel, le hook n'est pas attendu avec une extension
.sh
, justecommit-msg
.Merci d'être revenu. J'ai essayé même sans cette extension .sh mais cela ne fonctionne pas. Veuillez aider avec les étapes correctes sur la façon d'appliquer un hook pour tout commit dans le système local.
Hmm, étrange, je ne me souviens pas d'étapes supplémentaires, après avoir écrit ce fichier. Avez-vous revérifié le 1) chemin? (
.git / hooks
) 2) nom de fichier? (commit-msg
) 3) contenu? Désolé de demander, mais ces erreurs courantes sont si fréquentes et arrivent à tout le monde ... hors de cela, je ne peux pas encore comprendre quel pourrait être le problème.Appréciez l'aide ici. Mais oui, c'est tout ce que j'ai fait. Créé un dépôt de projet, initialisé avec git, placé un fichier commit-msg avec votre script. Ensuite, j'ai essayé de le tester en apportant une modification dans un fichier de projet suivi d'un message de validation normal. il ne s'est pas trompé. Y a-t-il quelque chose qui me manque dans tout le processus où j'ai juste besoin de tester ce hook dans mon référentiel git local.
Je ne peux pas vraiment dire après ce point, désolé, je suppose que nous devrons essayer de comprendre par un peu de test et de lecture sur le sujet ... quel peut être le problème?
Donc, selon vous, si j'utilise ce script exactement tel quel, alors tout commit dans mon local pour ce dépôt git devrait faire une vérification pour ce hook. pensez-vous que c'est parce que nous devons appliquer la politique d'une manière ou d'une autre? Je ne suis pas du tout familier avec cela, d'où la question. Il me semble pour le moment que les hooks git ne sont pas du tout appliqués, comme si git ignorait totalement cela. est-ce quelque chose que je dois également définir dans mon dépôt local .gitconfig ou peut-être global .gitconfig
J'essaie de rappeler quel élément j'aurais pu laisser comme acquis, mais pour l'instant, non, je ne vois rien d'autre puisque tout cela est local. Frustrant: - /
Ok maintenant, j'ai essayé presque tout, y compris la réinstallation du dernier git sur ma machine Windows. Assurez-vous que le git bin est sur le chemin. J'ai également essayé de remplacer le shebang par un chemin réel bash ou sh. Toujours pas de résultats. Vous ne savez pas comment puis-je tester ce simple hook dans mes fenêtres locales.Des suggestions supplémentaires?
Je suppose qu'il est temps de poser une question distincte. J'espère qu'on y répondra rapidement.
Ok une question ici. Comment cette expression regex valide-t-elle qu'il s'agit d'une clé d'émission jira valide. je veux dire que nous n'avons défini aucune URL jira, etc.