¿Dónde empujar una prueba fallida?

Acabo de cambiar la configuración de la bifurcación en mi repositorio de GitHub, de modo que mi [próxima] bifurcación requiere una compilación de CI pasante a través de una solicitud de extracción.

Siguió una discusión con varios miembros del equipo, sobre la falla de las pruebas.

Por el bien del contexto ...

El repositorio tiene una rama [maestra] en la que solo se introduce PR cuando hay una versión, por lo que [maestra] contiene el código de la última versión, independientemente de si es mayor, menor, revisión, beta, alfa / compilación previa al lanzamiento.

La rama [siguiente] es la "predeterminada", donde tenemos la intención de mantener el código "listo para liberar"; técnicamente, esa rama podría ser introducida en [maestro] en cualquier momento y liberada.

Los tenedores individuales tienen sus propias ramas de desarrollo, y los contribuyentes de relaciones públicas a [siguiente].

Cuando reviso un RP no trivial, fusionaré la rama de desarrollo del contribuyente en mi rama de "revisión", y si veo cosas que puedo solucionar rápidamente, comprometeré / empujaré cambios y nuevas pruebas (a veces fallidas), y PR volver a la rama de desarrollo del contribuyente; cuando combinen mis cambios, hagan pasar las nuevas pruebas fallidas y luego presionen, su PR se sincronizará, y luego fusionaré el PR en [siguiente].

Pero esta pregunta no se trata de pasar las pruebas, se trata de las que fallaron .

Las pruebas fallidas documentan lo que necesita ser reparado.

Los errores conocidos deben tener pruebas escritas, para que sepamos lo que no funciona.

Técnicamente, la lista de problemas de GitHub (filtrada por errores y / o etiquetas críticas ) también lo hace. ¿Es una buena práctica tener también un montón de pruebas fallidas para documentar errores?

Una acumulación fallar en [siguiente] significaría que no estamos listos para liberar ... pero entonces "ser comunicado listo" es un poco como "estar listo" para tener hijos - nunca se es bastante listo para esto, y algo, en algún lugar (de importancia variable) inevitablemente saldrá mal con el lanzamiento.

Así que solo estamos presionando las pruebas de aprobación para [siguiente]. ¿Dónde empujar las pruebas fallidas entonces? Quiero decir, ¿fuera del proceso de revisión / relaciones públicas?

Por ejemplo, un usuario informa un nuevo error en la lista de problemas, y me gustaría escribir un conjunto de pruebas fallidas para ello, a fin de especificar qué se debe hacer y dónde, lo que hace que sea más fácil para los nuevos contribuyentes recoger y eventualmente PR una solución.

¿Dónde debería estar empujando estas pruebas fallidas? ¿O es incluso una buena idea llevar las pruebas reprobadas a cualquier lugar?

Lo que haría en esta situación es marcar las pruebas fallidas como "ignoradas", de esa manera todavía tiene la prueba para que sepa lo que necesita arreglar en el futuro, pero no terminará con compilaciones rotas .

Si también etiqueta cada prueba con la referencia del rastreador de problemas para solucionar el problema, eso le brinda una manera fácil de vincular las cosas.

Divulgación completa: soy uno de los participantes en la discusión.

La rama maestra del repositorio no es su rama maestra. La fusión en master no tiene ningún "propósito real" y esa rama no está haciendo cosas que una rama debería hacer (es decir, moverse ).
Estás abusando de esta rama como una etiqueta para la última versión.

En lugar de usar una rama, use una etiqueta. Cuando desee liberar, realice los pasos necesarios en una "Rama de lanzamiento", al igual que una rama de tema. Luego fusionas eso en [siguiente] y le pones una etiqueta.

El papel que cumple [next] es el de una rama maestra. Solo entra el código listo para el lanzamiento. Cualquier otra cosa sería una rama [desarrollada]. Una rama de desarrollo contiene trabajo que debe estabilizarse . Esto significa: eliminar [maestro], reutilizar [siguiente] como ya lo hizo y crear otra rama para un trabajo "menos estable".

Dado que es más la excepción que la regla de que debe haber pruebas fallidas, que recuerden los errores pendientes, no debería ser un problema crear y destruir esa rama menos estable según sea necesario