Svantaggi della clonazione superficiale su Travis e altri servizi CI?

Question

La maggior parte dei servizi CI fornisce un modo per clonare un repository poco profondo. Per esempio, su Travis:

git: 
    depth: 1 

o AppVeyor:

clone_depth: 1 
or 
shallow_clone: true 

Questo ha il vantaggio evidente di velocità, dal momento che non c'è bisogno di clonare l'intero repository.

C'è qualche svantaggio nella clonazione superficiale sui servizi CI? C'è qualche situazione in cui un clone superficiale farebbe fallire una costruzione di CI? Altrimenti, perché la clonazione superficiale non è l'impostazione predefinita per questi servizi CI?

Answer 1

Ci sono due ragioni per cui di solito non accade.

In primo luogo, l'hash di un clone superficiale sarà diverso da qualsiasi versione che si può avere nel repository. Di conseguenza, non sarà possibile tenere traccia di una build che hai fatto a un determinato risultato.

In secondo luogo, la maggior parte dei server Git è in grado di inviare l'ottimizzato 'everything.pack' se non si dispone di dettagli. Altrimenti il ​​server dovrà fornire un pacchetto di commit personalizzato che contiene solo la tua copia superficiale da inviare a te. Quindi, anche se potrebbero esserci più dati trasmessi attraverso il cavo, potrebbe effettivamente comportare un aumento del lavoro sul server.

Infine un bel po 'di build CI eseguiranno una sorta di operazione di tag e la caricheranno nel repository, e non si può praticamente etichettare un clone poco profondo (vedi punto 1).

Answer 2

aggiunta alla risposta di AlBlue:

Un altro problema è che l'impostazione della profondità clone viene utilizzato anche per git modulo.

Nei progetti che utilizzano il sottomodulo git, Travis, ecc. Clonerà il repository del sottomodulo partendo dal master, quindi verificherà la revisione specifica.

Se il commit puntato nel sottomodulo non è all'interno di n commit del master corrente (dove n è l'impostazione di profondità), non riuscirà a effettuare il checkout.