Ciao,
Abbiamo bisogno di utilizzare questa nuova funzionalità/caratteristica per le email:
Poiché non è stata unita (presumiamo che lo sarà un giorno), qual è il modo consigliato per eseguire un discourse di produzione e includere una PR in revisione?
Presumo che dovremo evitare/non aggiornare discourse per gli aggiornamenti regolari, ma questo è probabilmente un approccio troppo semplicistico.
Qualsiasi guida su come altri lavorano in questo scenario sarebbe apprezzata.
Primo: Non lo so.
Ma penso che questo potrebbe funzionare:
cd /var/discourse
./launcher enter app
cd /var/www/discourse
su - discourse -c 'git fetch origin pull/<pr_number>/head:<local_branch_name>'
su - discourse -c 'git switch <local_branch_name>'
sv restart unicorn
Se funziona, potresti aggiungere elementi al tuo app.yml per farlo durante la build. O forse verrà unito presto e potrai semplicemente aspettare.
Se peggiora le cose, puoi fare un
./launcher destroy app;./launcher start app
e questo ripristinerà l’immagine che hai costruito l’ultima volta.
È molto utile, grazie. Idealmente vorremmo aspettare che venga unito, ma essendo nuovo a questo non è chiaro se si tratti di pochi giorni, settimane o mesi.
Grazie ancora.
Nessuna critica a questa PR (non l’ho guardata in dettaglio), ma in generale non penso sia una buona pratica.
Sfrutta la revisione degli sviluppatori CDCK e attendi che venga revisionato e fuso?
Questo è un buon consiglio.
Con quello che ho suggerito, potresti essere in grado di vedere che funziona effettivamente (o forse ci sono specifiche che rispondono a quella domanda), o andare avanti per un po’ finché non viene accettato. Molte persone aspettano settimane (o mesi) per aggiornare comunque.
@merefield grazie - credo che tu stia dicendo di aspettare che venga unito, è corretto?
Siamo d’accordo, è un’ottima idea. Nel frattempo, tuttavia, dobbiamo gestire i rimbalzi delle email.
Di nuovo, non sappiamo quanto tempo richiederà il processo, quindi senza quella conoscenza, assumeremo che richiederà molto tempo.
Forse mi sfugge qualche sfumatura…
Penso che tu possa tranquillamente provarlo per qualche settimana. Se ci sarà un’altra release, potrai decidere se aggiornare la tua PR per farla funzionare con la prossima release o trovare un’altra soluzione. Probabilmente la cosa più semplice sarebbe farla in un plugin?
Aspetta. Perché non farla semplicemente in un plugin?
Questa è la procedura usuale. Fallo in un plugin e poi chiedi se sarebbero interessati a una PR. Al momento, sembra che tu sia l’unico sul pianeta a volerlo. Aggiungerlo al core significa che qualcuno dovrà mantenerlo indefinitamente; non è banale.
Sì, non capisco perché questo non sia implementato in un plugin.
Quindi potresti semplicemente far evolvere il plugin separatamente dall’installazione principale.
Una volta (se) la PR verrà unita, potresti quindi rimuovere il plugin!
Dobbiamo anche risolvere questo problema per le patch di sicurezza non pubbliche.
Abbiamo del codice nei nostri strumenti interni che esegue il merge di un branch da un repository - raccomanderei lo stesso approccio per te.
Qualcosa di simile dovrebbe funzionare per te in un blocco exec (probabilmente nell’hook after_code):
# recupera ed esegui il merge della patch
git merge REFERENCE --no-commit
bundle install # se necessario
pnpm install --frozen-lockfile # se necessario
@merefield @pfaffman non è un plugin semplicemente perché, per noi, non è banale. Non abbiamo mai scritto un plugin. Se qualcuno ha indicazioni su come collegarlo, saremmo felici di esaminarlo!
Inoltre, probabilmente non direi che siamo l’unica persona che “vuole” netcore - è uno dei più grandi ESP… sulla terra, e molte volte più grande di alcuni degli altri supportati nel core. Non sto suggerendo che sia migliore, o che gli utenti possano volere gli altri, ma netcore è un ESP molto grande e ben considerato. Infatti, puoi vedere molte discussioni a riguardo qui, poiché in precedenza era pepipost:
Ritengo che una doppia strategia sarebbe appropriata:
Non essere in grado di creare un plugin non è un’ottima ragione per fare una pull request.
Terze parti potrebbero comunque utilizzare il tuo plugin.
@merefield mi dispiace, perché pensi che la build del plugin sia correlata alla creazione della PR? Netcore stessi hanno scritto la PR.
Forse mi sfugge qualche dettaglio in quello che stai dicendo.
Solo un suggerimento. Ti offre maggiore flessibilità sulle tempistiche di distribuzione. A chi non piacciono meno dipendenze?
Perché puoi creare un plugin.
Non sai se accetteranno mai la tua PR. E nemmeno io.
Ecco un suggerimento: Qualcuno del Team ha risposto in questo argomento e non ha detto “Sì, lo stiamo integrando al più presto”. Invece ti ha detto “Ecco cosa facciamo se abbiamo una PR che non verrà accettata nel core per mesi”.
Sembra che queste siano le tue opzioni.
Non darei troppo peso alla mia risposta.
Sono nel team infrastrutture, non ho alcuna visione delle priorità dei team di sviluppo. Per me il commit sembra 
ma un occhio più esperto potrebbe avere un’opinione diversa.
Ma penso che rispondere a questa domanda sarebbe un consiglio / FAQ generalmente utile per gli self-hoster.
Secondo me un plugin sarebbe troppo pesante qui.
Beh, dimostra cosa so.
E continuo a dimenticare quanto sia grande lo staff ora e quanto debbano essere segmentati i team. Sembra ieri che la maggior parte di tutti conosceva quasi tutto (ovviamente anche allora le persone avevano le loro nicchie), ma quel “ieri” è stato otto anni fa.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.