I, [2020-12-05T10:59:38.848743 #1] INFO -- : > cd /var/www/discourse && git remote set-branches origin v2.6.0
I, [2020-12-05T10:59:38.852600 #1] INFO -- :
I, [2020-12-05T10:59:38.852639 #1] INFO -- : > cd /var/www/discourse && git fetch --depth 1 origin v2.6.0
From https://github.com/discourse/discourse
* tag v2.6.0 -> FETCH_HEAD
I, [2020-12-05T10:59:41.405163 #1] INFO -- :
I, [2020-12-05T10:59:41.405307 #1] INFO -- : > cd /var/www/discourse && git checkout v2.6.0
error: pathspec 'v2.6.0' did not match any file(s) known to git
I, [2020-12-05T10:59:41.411796 #1] INFO -- :
Invece dell’output previsto quando si utilizza il commit immediatamente precedente:
I, [2020-12-05T11:22:14.717910 #1] INFO -- : > cd /var/www/discourse && git fetch origin v2.6.0
From https://github.com/discourse/discourse
* tag v2.6.0 -> FETCH_HEAD
I, [2020-12-05T11:22:15.672616 #1] INFO -- :
I, [2020-12-05T11:22:15.672683 #1] INFO -- : > cd /var/www/discourse && git checkout v2.6.0
Note: checking out 'v2.6.0'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b <new-branch-name>
HEAD is now at d6121249d3 Version bump to v2.6.0
Non lo definirei un vero e proprio bug, ma vogliamo fornire delle istruzioni su come installare versioni precedenti di Discourse, anche se ciò comporta l’uso di un template più complesso o qualcosa di simile.
Sono d’accordo: la profondità dovrebbe essere configurabile, magari tramite una variabile d’ambiente, con valore predefinito “shallow”, ma rendibile configurabile semplicemente tramite una variabile d’ambiente.
Credo che il problema qui sia che i tag non sono noti localmente durante il checkout, come nel seguente problema (non correlato a Discourse):
Eseguire git fetch --all dovrebbe risolvere il problema, ma non so quanto potrebbe aumentare le dimensioni dell’immagine (a meno che un’altra istruzione non pulisca i riferimenti non utilizzati in seguito).
Detto questo, credo che git clone --depth 1 https://github.com/discourse/discourse.git --branch=$version risolverebbe il problema, poiché --branch accetta sia rami che tag, ma non l’ho testato e non so se ci sia un motivo per cui il clone utilizzi (attualmente) il ramo master.
Eseguendo git clone --depth 1 https://github.com/discourse/discourse.git --branch=v2.6.0, la dimensione dell’intera cartella è di 212MB e la cartella .git all’interno ha 46MB, quindi penso vada bene.
Il problema è che al momento della costruzione dell’immagine non so quale ramo vorrai in futuro.
La configurazione attuale è stata modificata per ridurre le dimensioni dell’immagine, ottenendo una riduzione del 25% (250 MB) sulle dimensioni compresse, il che è un grande successo. Funziona bene quando si utilizzano rami normali come stable e beta o tests-passed.
Come soluzione temporanea, se desideri passare a un tag, puoi applicare quanto segue al tuo file app.yml:
Un’altra soluzione temporanea consiste nell’aggiungere una chiave base_image al livello superiore di app.yml con il valore di un’immagine base più vecchia. Dato che non cerchiamo nemmeno di mantenere la compatibilità tra le nuove immagini in grado di eseguire versioni precedenti di Discourse, questo potrebbe essere necessario se si torna indietro di molto nel tempo.
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?
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.
Sì, vedo che esegue un fetch e poi un checkout sul ramo corretto dopo il pull, quindi penso che il git pull non sia necessario (non l’ho ancora testato, però).
Per i tag sembra che debba ancora recuperarli separatamente, ma sembra fattibile. Inoltre, i rami sono più comunemente usati, quindi i tag dovrebbero essere più un caso limite.
Sto ricevendo lo stesso errore. Stavo usando la versione 2.5.1.
A seguito di ciò, ricevo il seguente errore:
I, [2020-12-31T11:50:24.701475 #1] INFO -- : > cd /var/www/discourse && find /var/www/discourse ! -user discourse -exec chown discourse {} \+
chown: impossibile risolvere il riferimento per '/var/www/discourse/public/plugins/styleguide': File o directory non esistente
Affinché ciò funzioni, non dovresti usare la chiave di livello superiore version nel tuo file app.yml, ma solo quel nuovo codice. Facendo così, non si verifica alcun errore.
Grazie per aver chiarito: è esattamente la parte che mi mancava. Per chi, come me, era confuso, ottenere un tag di rilascio di Discourse si può fare così:
Assicurarsi che il parametro versionnon sia impostato in app.yml, ad esempio:
