Regressione superficiale di git fetch in discourse_docker

Hai ragione, in quel momento non conosciamo la versione; sembra che l’immagine di base utilizzi la versione corrente più il ramo tests-passed, anche se il ramo conterrà il commit esistente al momento della costruzione dell’immagine.

Il metodo attualmente utilizzato non comporterebbe rebuild più lenti, anche quando viene utilizzato il ramo tests-passed?

Considera semplicemente le seguenti istruzioni:

Nell’immagine di base:

git clone --depth 1 https://github.com/discourse/discourse.git
cd discourse/
git remote set-branches --add origin tests-passed

In web.template.yml

git reset --hard
git clean -f
git remote set-branches --add origin master
git pull
...
Quando viene chiamato `git pull`, **l'intero repository viene scaricato** e può richiedere diversi minuti, perché in precedenza è stato effettuato solo un clone parziale. Puoi provare a eseguire solo le istruzioni sopra indicate in locale e verificare. Non sto dicendo che sia meglio avere l'intero repository nell'immagine di base, ma il codice in `web.template.yml` viene eseguito ad ogni rebuild, anche se è stato aggiunto solo un plugin o modificata una impostazione in `app.yml`. Normalmente, nei miei progetti (non Discourse), creo una nuova immagine per ogni nuova versione, ma questo potrebbe non essere fattibile per te (considerando come lo fai attualmente). Non hai notato un aumento dei tempi di rebuild? (o forse non è così significativo rispetto al tempo totale di rebuild nella maggior parte dei casi)

Aggiornamento

Ho riprovato le istruzioni sopra indicate e sono state veloci. Immagino che al primo tentativo avessi eseguito un’altra istruzione che ha modificato l’albero git, finendo per scaricare tutto quando ho eseguito git pull.

2 Mi Piace