Ho appena cambiato le impostazioni delle filiali sul mio repository GitHub, in modo che il mio ramo [successivo] richieda una build CI passante attraverso una richiesta pull.
Una discussione seguita con un numero di membri del team, sui test falliti.
Per ragioni di contesto ...
Il repository ha un ramo [master] in cui è presente solo PR quando c'è un rilascio, quindi [master] contiene il codice di l'ultima release, indipendentemente dal fatto che sia un major, un minore, un hotfix, una versione beta, alpha / pre-release.
Il ramo [successivo] è quello "predefinito", dove intendiamo per mantenere il codice "pronto per la release"; tecnicamente quel ramo potrebbe essere convertito in [master] in qualsiasi momento e rilasciato.
I singoli forch hanno le proprie dir di sviluppo e le pubbliche relazioni di contributori a [successivo].
Quando recensisco un PR non banale, unirò il ramo dev del contributore al mio ramo "recensione" e, se vedo cose che posso sistemare rapidamente, commetterò / sposterò cambiamenti e nuovi (a volte fallendo) i test e PR di nuovo nel ramo dev del contributore; quando si uniscono i miei cambiamenti, fanno passare i nuovi test falliti e poi spingono, i loro PR si sincronizzano, e poi unirò il PR in [next].
Ma questa domanda non riguarda i test che passano , riguarda i fallimenti .
Failing tests document what needs to be fixed.
Known bugs should have tests written for, so that we know what's not working.
Tecnicamente l'elenco Emissioni di GitHub (filtrato per > / a> e / o critiche etichette ) fa anche questo. È una buona pratica per anche avere 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" ad avere figli - non sei mai abbastanza pronto per questo, e qualcosa, da qualche parte (di importanza variabile) inevitabilmente andrà male con il rilascio.
Quindi stiamo solo spingendo i test di passaggio a [successivo]. Dove spingere i test in mancanza, allora? Voglio dire, al di fuori del processo di revisione / PR?
Ad esempio, un utente segnala un nuovo bug nella lista dei problemi, e mi piacerebbe scrivere una suite di test in errore per questo - in modo da specificare cosa deve essere fatto e dove, cosa che rende più facile per i nuovi contributori per prendere e alla fine PR una correzione.
Dove devo spingere questi test falliti? O è anche una buona idea spingere i test falliti da qualche parte?