Dove spingere un test fallito?

Ho appena modificato le impostazioni del ramo sul mio repository GitHub, in modo che il mio ramo [successivo] richieda un build CI di passaggio attraverso una richiesta pull.

Segue una discussione con alcuni membri del team sui test falliti.

Per amor di contesto ...

Il repository ha un ramo [maestro] che è PR'd solo in quando c'è un rilascio, in modo [maestro] contiene il codice a partire dal l'ultima release, indipendentemente dal fatto che si tratta di un grande, un minore, una correzione, una beta, alpha / build pre-release.

Il ramo [successivo] è quello "predefinito", dove intendiamo mantenere il codice "pronto per il rilascio"; tecnicamente quel ramo potrebbe essere messo in PR in qualsiasi momento e rilasciato.

Le singole forcelle hanno i loro rami di sviluppo e contribuiscono da PR a [next].

Quando rivedo un PR non banale, unirò il ramo dev del contributore nel mio ramo "review", e se vedo cose che posso sistemare velocemente commetto / spingo modifiche e nuovi test (a volte falliti) e PR di nuovo nel ramo di sviluppo del collaboratore; quando uniscono le mie modifiche, fanno passare i nuovi test non riusciti e quindi spingono, il loro PR si sincronizza, quindi unirò il PR in [successivo].

Ma questa domanda non riguarda il superamento dei test, riguarda quelli che falliscono .

Test falliti documentano ciò che deve essere risolto.

I bug noti dovrebbero avere test scritti, in modo da sapere cosa non funziona.

Tecnicamente GitHub elenco dei problemi di (filtrato per bug e / o etichette critiche ) lo fa. È buona norma avere anche un sacco di test falliti per documentare i bug?

Una build fallita su [next] significherebbe che non siamo pronti per il rilascio ... ma poi "essere pronti per il rilascio" è un po 'come "essere pronti" per avere figli - non sei mai del tutto pronto per questo, e qualcosa, da qualche parte (di importanza variabile) inevitabilmente andrà storto con il rilascio.

Quindi stiamo spingendo sempre e solo a passare i test a [successivo]. Dove spingere i test falliti allora? Voglio dire, al di fuori del processo di PR / revisione?

Ad esempio, un utente segnala un nuovo bug nell'elenco dei problemi e mi piacerebbe scrivere una suite di test non riuscita per questo - in modo da specificare cosa deve essere fatto e dove, il che rende più facile la raccolta di nuovi collaboratori e infine PR una correzione.

Dove dovrei spingere questi test falliti? O è anche una buona idea spingere i test falliti ovunque?

Quello che farei in questa situazione è di contrassegnare i test falliti come "ignorati" - in questo modo hai ancora il test in modo da sapere cosa devi correggere in futuro, ma non finirai con build rotte .

Se tagghi anche ogni test con il riferimento del tracker dei problemi per risolvere il problema, questo ti dà un modo semplice per legare le cose.

Divulgazione completa: sono uno dei partecipanti alla discussione.

Il ramo principale del repository non è il ramo principale. La fusione in master non ha alcun "scopo reale" e quel ramo non sta facendo cose che dovrebbe fare un ramo (vale a dire spostare ).
Stai abusando di questo ramo come tag dell'ultima versione.

Invece di usare un ramo, usa un tag. Quando desideri rilasciare, esegui i passaggi necessari in un "Ramo di rilascio", proprio come un ramo di argomento. Quindi lo unisci in [successivo] e metti un Tag su di esso.

Il ruolo che [successivo] svolge, è quello di un ramo principale. Solo il codice pronto per il rilascio va inserito lì. Qualsiasi altra cosa sarebbe un ramo [sviluppo]. Un ramo di sviluppo contiene lavoro che deve essere stabilizzato . Ciò significa: rimuovere [master], riutilizzare [next] come già fatto e creare un altro ramo per un lavoro "meno stabile".

Dal momento che è più un'eccezione che una regola che non deve superare i test, che ricordano i bug in sospeso, non dovrebbe essere troppo un problema creare e distruggere quel ramo meno stabile secondo necessità