Ho visto spesso processi di compilazione automatizzati, incluse le build di Continuous Integration, il commit delle modifiche apportate ai file di origine durante il build nel repository di controllo della versione originato da *. I numeri di versione con incremento automatico sono uno scenario comune in cui viene eseguita questa operazione, ma ce ne sono altri.Un processo di compilazione automatizzata dovrebbe commettere modifiche al controllo versione?
La mia intuizione è che questa è una cattiva idea in quanto può lettiera la storia repository con commit costruire legate e il processo di costruzione ha bisogno di evitare che accidentalmente il re-innescare stesso. Tuttavia non ho alcuna prova concreta che sia meglio evitare di commettere modifiche durante una costruzione.
Qualcuno può citare riferimenti che discutono i pro e i contro di commit delle modifiche al controllo della versione durante una compilazione automatizzata?
* È possibile accettare le modifiche apportate a un repository di elementi distinti.
Ho considerato il problema di essere in grado di riprodurre una build, ma se una build eseguita contro la versione N riporta una modifica al controllo del codice sorgente e crea la versione N + 1, la ripetizione della build rispetto alla versione N sarà ignorante di N + 1 e non dovrebbe cambiare l'output. –
@JasonStangroome: ma creerà inutilmente la versione N + 1 più e più volte. Basta non farlo. Non ha uno scopo utile. CI parla di * leggere e costruire, non scrivere niente. – VonC