Cercando di capire cosa fa Travis CI e quando dovrebbe essere usato

Naviga le tue risposte
3

Sono molto nuovo a Git e sto pensando di contribuire a qualche progetto open-source su GitHub dopo aver scoperto un piccolo errore in esso. Dopo averlo forato e corretto l'errore, ho proposto una richiesta di pull e ho notato che questo si presentava:

Failed — The Travis CI build failed

Guardando nei dettagli ho scoperto che era causato da Could not find .travis.yml , il che era perfettamente logico dal momento che non avevo firmato con Travis Cl e aggiungo .travis.yml al repository.

Questa è la mia prima volta che ascolto di Travis CI. E sembra abbastanza bello quindi per saperne di più, ho cercato su Wikipedia.

Travis CI is a hosted, distributed continuous integration service used to build and test projects hosted at GitHub. Travis CI automatically detects when a commit has been made and pushed to a GitHub repository that is using Travis CI, and each time this happens, it will try to build the project and run tests. This includes commits to all branches, not just to the master branch.

La mia attuale comprensione di Travis CI è che ciò che fa spinge automaticamente il progetto su git commit -am ".." e non ne capisco una parte.

  1. Per costruzione del progetto ed esecuzione di test , quali test verrà eseguito? E come sta andando a "costruire" il progetto? (come compilarlo in binario?)

  2. Si afferma che "Questo include commit a tutti i rami" - ma cosa succede se non voglio impegnarmi in tutti i rami?

  3. Va bene se non uso affatto Travis Cl? In quali circostanze è meglio usarlo (o deve essere usato)?

posta trying to figure it out 23.03.2014 - 00:39
fonte

1 risposta

2

  1. Qualsiasi test faccia parte del progetto complessivo. Test unitari e test di integrazione fanno parte di alcuni progetti che dovrebbero essere eseguiti dopo che sono state apportate modifiche al codice per garantire che la funzionalità funzioni ancora come inizialmente previsto. Potrebbe essere necessario modificare i test non riusciti o potrebbero esserci dei bug che sono stati ignorati nella modifica iniziale del codice. C'è probabilmente un qualche tipo di makefile nel progetto che viene utilizzato per compilare il progetto in qualsiasi forma finale ha, ad esempio un eseguibile, DLL, sito Web o altro componente.

  2. Sebbene possa esserci un'opzione per cambiarlo da qualche parte, è possibile che le modifiche siano destinate a tutte le versioni future e quindi il commit dovrebbe riflettersi in tutti i rami in sospeso che penserei.

  3. Ciò può dipendere da chi gestisce il progetto, in quanto l'idea generale di CI è di verificare che un commit non rompe il software o i test. Si consideri il caso che se si commette un codice con errori di battitura che non viene compilato. Questo è in genere cattivo e un server CI lo catturerà rapidamente in modo che possa essere riparato. Allo stesso modo, potrebbero esserci test di regressione che di solito non vengono eseguiti che un server CI può rilevare quando gli sviluppatori commettono le loro modifiche. Alcune persone credono nell'idea che il commit non dovrebbe rompere la build mai e quindi si limita a commettere solo una volta che le cose funzionano, mentre altri credono in un cambiamento spesso commettente, sia che rompa la build o meno. Quando eseguire il commit del codice ha varie risposte che possono essere utili su questo punto.

risposta data 23.03.2014 - 06:23
fonte

Leggi altre domande sui tag

posso vendere un software che utilizza una libreria GPL e un'altra libreria con licenza BSD? Devo internazionalizzare la visualizzazione dei valori esadecimali?