Où pousser un test qui échoue?

Je viens de modifier les paramètres de branche sur mon référentiel GitHub, de sorte que ma [prochaine] branche nécessite une construction CI en passant par une demande d'extraction.

Une discussion s'ensuit avec un certain nombre de membres de l'équipe sur l'échec des tests.

Par souci de contexte ...

Le référentiel a une branche [master] qui n'est PR que lorsqu'il y a une version, donc [master] contient le code de la dernière version, qu'il s'agisse d'une version majeure, mineure, d'un correctif, d'une version bêta, alpha / version préliminaire.

La branche [suivante] est la branche "par défaut", où nous avons l' intention de conserver le code "prêt pour la publication"; techniquement, cette branche peut être insérée dans [master] à tout moment et libérée.

Les fourches individuelles ont leurs propres succursales de développement et les contributeurs PR à [suivant].

Lorsque je passe en revue un PR non trivial, je fusionne la branche de développement du contributeur dans ma branche "Review", et si je vois des choses que je peux résoudre rapidement, je valide / pousse les modifications et les nouveaux tests (parfois échouant), et PR de retour dans la branche de développement du contributeur; quand ils fusionnent mes modifications, font passer les nouveaux tests qui échouent, puis poussent, leur PR se synchronise, puis je fusionne le PR dans [suivant].

Mais cette question ne concerne pas la réussite des tests, elle concerne les échecs .

Les tests manquants documentent ce qui doit être corrigé.

Les bogues connus devraient avoir des tests écrits pour que nous sachions ce qui ne fonctionne pas.

Techniquement, la liste des problèmes GitHub (filtrée pour les étiquettes de bogues et / ou critiques ) le fait aussi. Est-ce une bonne pratique d' avoir également un tas de tests qui échouent pour documenter les bogues?

Un build échoué sur [suivant] signifierait que nous ne sommes pas prêts à sortir ... mais alors "être prêt à sortir" est un peu comme "être prêt" à avoir des enfants - vous n'êtes jamais tout à fait prêt pour cela, et quelque chose, quelque part (d'importance variable) ira inévitablement mal avec la version.

Nous ne faisons donc que pousser les tests de réussite à [suivant]. Où pousser les tests qui échouent alors? Je veux dire, en dehors du processus PR / examen?

Par exemple, un utilisateur signale un nouveau bogue dans la liste des problèmes, et j'aimerais lui écrire une suite de tests défaillante - afin de spécifier ce qui doit être fait et où, ce qui facilite la tâche des nouveaux contributeurs. et finalement PR un correctif.

Où dois-je pousser ces tests qui échouent? Ou est-ce même une bonne idée de pousser les tests ayant échoué n'importe où?

Ce que je ferais dans cette situation est de marquer les tests ayant échoué comme "ignorés" - de cette façon, vous avez toujours le test pour savoir ce que vous devez corriger à l'avenir, mais vous n'allez pas vous retrouver avec des builds cassés .

Si vous marquez également chaque test avec la référence de suivi des problèmes pour résoudre le problème, cela vous permet de lier facilement les choses.

Divulgation complète: je suis l'un des participants à la discussion.

La branche principale du référentiel n'est pas sa branche principale. La fusion en master ne sert aucun "objectif réel" et cette branche ne fait pas les choses qu'une branche devrait faire (à savoir se déplacer ).
Vous abusez de cette branche en tant que balise de la dernière version.

Au lieu d'utiliser une branche, utilisez une balise. Lorsque vous souhaitez publier, vous effectuez les étapes nécessaires dans une "Release-Branch", tout comme une branche de sujet. Ensuite, vous fusionnez cela dans [suivant] et mettez un tag dessus.

Le rôle que [suivant] remplit est celui d'une branche maître. Seul le code prêt à être publié y entre. Tout le reste serait une branche [develop]. Une branche de développement contient du travail à stabiliser . Cela signifie: supprimer [master], réutiliser [suivant] comme vous l'avez déjà fait et créer une autre branche pour un travail "moins stable".

Étant donné que c'est plus l'exception que la règle selon laquelle il doit y avoir des tests qui échouent, qui rappellent les bogues en suspens, cela ne devrait pas être trop difficile de créer et de détruire cette branche moins stable au besoin