2015-07-10 34 views
13

Per quanto ho capito, la differenza principale è che gitlab-ci è opensource (è possibile installarlo sul proprio server) e travis-ci non lo è.Come confrontare travis-ci e gitlab-ci?

Quindi, quest'ultimo è sempre basato su cloud/servizi. Ed è gratuito per progetti open source.

Ma poi GitLab.com (la società, non il software) ha anche una versione cloud che non è necessario installare: ci.gitlab.com. E suppongo che questa versione possa essere utilizzata solo con repository pubblici pubblicati nel tuo account Gitlab.

Ma poi, non c'è quasi nessuna documentazione sull'esecuzione di GitLab CI in questo modo. La maggior parte dei documenti che trovo riguardano l'installazione del server GitLab CI o dei corridori. Ma come sono configurati i corridori di ci.gitlab.com? Che sistema operativo hanno? Posso avere corridori Windows/Mac? (Il software supporta questi sistemi operativi a quanto pare, ma non è specificato quale i corridori sono forniti dal servizio di ci.gitlab.com.)

+3

Anche se mi interessa, sto votando per chiudere questa domanda come off-topic perché sta chiedendo "Consigli di prodotto o servizio o confronti", che è fuori tema come per http://stackoverflow.com/tour . – phunehehe

+0

Dovrei anche notare che i corridori liberi di base docker sembrano funzionare proprio ora. – phunehehe

risposta

14

Edit: 29/06/2016

Come commenti suggeriscono, ora sta offrendo gitlab quelli che chiamano corridori condivisi. Ciò significa che non è più necessario portare il proprio runner, è possibile utilizzare invece il proprio e utilizzarlo proprio come travis CI, ma c'è un limite di 2.000 minuti di tempo di esecuzione CI al mese per il livello gratuito.

** precedente risposta storica **

Gitlab CI può essere utilizzato on-line, ma è necessario portare i propri corridori. Cosa significa questo? È necessario installare un software nei propri server che eseguirà i test. È più complesso di Travis.

Dopo l'installazione, è necessario associarlo al progetto e configurarlo se si desidera eseguire test nella finestra mobile o nel proprio hardware. Ci sono poche altre opzioni.

Ogni volta che si preme un commit su gitlab, viene attivato un hook su gitlab ci e una build viene inviata a un runner disponibile che esegue la build e verifica e invia i risultati dei test al server gitlab ci.

Ora, con l'ultimo aggiornamento, gitlab ci si trova all'interno di gitlab, ma è sempre lo stesso.

+4

** Sì, questa risposta deve cambiare. ** Purtroppo, nessuno può aggiungere risposte concorrenti ora. La risposta di 500 caratteri, pertanto, è quella di leggere l'articolo pubblicato di recente ["GitLab.com Shared Runners utilizza la scalabilità automatica"] (https://about.gitlab.com/2016/04/05/shared-runners). La linea chiave è: "Tutte le tue build girano su istanze Digital Ocean da 4 GB, con CoreOS e l'ultimo Docker Engine installato". _Tutti i progetti pubblici e privati ​​ospitati su 'gitlab.com' possono quindi consentire l'integrazione continua basata su Linux, basata su Docker e basata su" Condivisi condivisi ". –

+1

Per continuare la risposta precedente, annotare l'aggettivo critico "basato su Linux". Sì, è giusto! Sebbene Docker supporti in modo trasparente le versioni recenti di OS X _and_ Windows, i Runner condivisi predefiniti forniti da 'gitlab.com' fanno _non_. È Linux o nuthin '... ** per ora. ** Nel momento in cui leggi questo, tuttavia, questo vincolo nocivo potrebbe essere stato rilassato o addirittura eliminato. Tieni i tuoi occhietti ben aperti sul [blog ufficiale di GitLab] (https://about.gitlab.com/blog), il loro log delle modifiche leggibile dall'uomo, per i dettagli aggiornati. Tutto è in divenire. Ed è buono –