À propos des hooks de pré-réception
Quand une poussée (push) est effectuée, chaque script s’exécute dans un environnement isolé et peut effectuer des vérifications sur le contenu de la poussée. Les scripts déclenchent l’acceptation de la poussée si l’état de sortie est 0 ou son rejet si l’état de sortie n’est pas zéro.
Utilisez des hooks de pré-réception pour répondre aux règles métier, appliquer la conformité réglementaire et prévenir certaines erreurs courantes.
Exemples de la façon dont vous pouvez utiliser des hooks de pré-réception :
- Exiger que les messages de commit suivent un modèle ou un format spécifique, par exemple qu’ils incluent un numéro de ticket valide ou respectent une certaine longueur
- Verrouiller une branche ou un dépôt en rejetant toutes les poussées
- Empêcher l’ajout de données sensibles au dépôt en bloquant des mots clés, des modèles ou des types de fichiers
- Empêcher l’auteur d’une demande de tirage (pull request) de fusionner ses propres modifications
Vous pouvez voir des exemples de hooks de pré-réception pour GitHub Enterprise Server dans le dépôt github/platform-samples.
Impact sur les performances et les workflows
L’impact sur les développeurs et leurs workflows peut être important et doit être considéré avec attention. Les hooks de pré-réception basés sur des besoins métier et implémentés de manière réfléchie sont ceux qui offrent le plus d’avantages à l’organisation dans son ensemble.
Les hooks de pré-réception peuvent avoir des effets inattendus sur les performances de votre instance GitHub Enterprise Server et doivent être implémentés et vérifiés attentivement.
En raison du risque d’échec et d’impact sur les performances pour tous les utilisateurs de votre instance, voici nos recommandations.
- Évitez les demandes d’API au sein d’un hook de pré-réception. En particulier, nous déconseillons fortement d’effectuer des demandes à des services externes, ce qui peut prendre plus de temps et entraîner un impact sur les performances.
- Évitez les opérations Git de longue durée au sein d’un hook de pré-réception. Si votre hook de pré-réception effectue des opérations Git dans des dépôts volumineux ou occupés, les performances globales de votre instance peuvent être affectées négativement.
Remarque
Pour éviter le rejet d'une requête en raison d'un dépassement de délai, tous les crochets de pré-réception combinés doivent être exécutés en moins de cinq secondes.
Délais d’expiration du hook de pré-réception
Les hooks de pré-réception dans GitHub Enterprise Server ont un délai d'expiration fixe de 5 secondes (partagé entre tous les hooks). Il s'agit d'une conception intentionnelle pour empêcher l'épuisement des ressources des hooks de longue durée et empêcher les scripts incontrôlés de bloquer les opérations sur le référentiel indéfiniment.
Tous les hooks de pré-réception pour un référentiel partagent un budget de délai d’attente cumulé :
- Si le crochet A prend 3 secondes, le crochet B obtient 2 secondes restantes (à partir de 5 secondes par défaut)
- Si le hook A expire après 5 secondes, le hook B ne s'exécute pas.
Important
Les délais d’expiration du hook de pré-réception sont gérés différemment des codes de sortie :
-
**Codes de sortie** : la configuration d'application est respectée (les crochets non appliqués ne bloquent pas les poussées) -
**Délais d’expiration** : l’envoi peut échouer, quelle que soit la configuration de l'application de contraintes
Comportement de délai d'expiration
| Scénario | Mise en application = Activée | Mise en œuvre = Désactivée/Test |
|---|---|---|
| Code de sortie ≠ 0 | Push rejeté | Le push continue (avertissement uniquement) |
| Dépassement du délai d’expiration | Push rejeté | Avertissement : l'envoi push peut encore échouer |