Choisir où Taiga attend une décision

Séparer quatre décisions

Le service fictif d’équipement comporte quatre décisions différentes : accepter le plan, exécuter le build, merger la modification et la déployer. Ne traitez pas un seul interrupteur comme une autorisation des quatre.

Avant de modifier l’autonomie, examinez ce que fait le pipeline du dépôt après le merge. Si le merge vers la branche de travail déclenche un déploiement, un merge automatisé peut aussi déclencher ce processus existant.

Décider si un plan attend

Le réglage produit Build on its own by default contrôle si un plan terminé passe à la construction ou attend une approbation. Désactivez-le lorsque les plans nécessitent d’abord une décision humaine.

Le réglage Build on its own d’une initiative peut modifier ce comportement pour cette initiative. Examinez le réglage par défaut et les choix particuliers avant de placer le travail dans la file.

Approve lance la construction sous l’identité de la personne qui approuve, selon ses permissions actuelles. Un plan échoué ne lance aucune construction. Automatiser la construction n’autorise pas à lui seul le merge de la pull request obtenue.

Comprendre la hiérarchie du merge

Le merge autonome est contrôlé séparément et reste désactivé tant qu’il n’est pas activé. L’intégration documentée prend en charge GitHub, y compris GitHub Enterprise.

Un plafond désactivé au niveau de l’organisation ou de la factory ne peut pas être contourné en dessous. Un réglage produit désactivé par défaut est différent : une initiative peut activer son propre merge si les plafonds le permettent.

Pour le service d’équipement, gardez un périmètre initial explicite. Une initiative aux conséquences limitées peut avoir un choix différent d’une modification des contrôles d’accès des salariés, dans les limites autorisées.

Rendre les revues requises exécutoires

Taiga demande au fournisseur de gestion de code si la pull request peut être mergée. Votre protection de branche détermine les contrôles, revues et autres conditions requis. Le merge autonome ne contourne pas ces règles.

Si une revue automatisée doit bloquer le merge, rendez son résultat obligatoire comme contrôle de statut dans la configuration prise en charge par le dépôt. Un résultat consultatif ne devient pas obligatoire parce que vous vous y attendez.

Vérifiez aussi les approbations humaines requises. Un contrôle vert ne remplace pas une approbation exigée par votre politique. Confirmez les règles de la branche cible réelle.

Interpréter un merge arrêté

Lisez la raison sur l’initiative. Un contrôle en attente, une approbation manquante, un conflit et un plan incomplet appellent des réponses différentes. Taiga arrête aussi le merge autonome lorsque les corrections modifient les critères qui ont permis à des contrôles échoués de réussir. Examinez directement cette modification.

Ne supprimez pas un contrôle requis simplement parce qu’il bloque le progrès. S’il ne renvoie jamais de résultat, corrigez sa configuration ou suivez la procédure autorisée de modification des règles. Examinez le commit actuel après chaque correction.

Garder l’autorisation de déploiement distincte

La GitHub App de Taiga effectue le merge autonome et est enregistrée comme son auteur. Le pipeline du dépôt conserve son comportement de déploiement existant.

Dans ce scénario, le merge déploie en staging. La production exige toujours la décision de production de l’organisation et ses preuves. Confirmez que le pipeline impose cette séparation. Poursuivez avec la revue de livraison.