Ci ho giocato e ho trovato una soluzione su Github.
Quindi un semplice segno di spunta verde per l’ultimo job CI non è abbastanza buono, poiché le cose potrebbero essere cambiate di recente, il che potrebbe rompere il plugin. Fondamentalmente è necessario rieseguire i job CI quando Discourse aggiorna i branch.
In questo repository di esempio ho elaborato una soluzione efficiente. Si tratta fondamentalmente di un workflow pianificato che controlla i branch importanti del repository Discourse per vedere se ci sono cambiamenti, se ci sono attiverà il normale workflow CI che dovrebbe eseguire la suite di test. Nel tuo readme puoi quindi inserire alcuni badge per mostrare come i workflow CI sono stati eseguiti rispetto alle modifiche più recenti.
Il workflow di monitoraggio viene eseguito in pochi secondi. Quindi, quando pianificato, consumerebbe solo 1 minuto di tempo di azione di GitHub.
Ovviamente l’affidabilità di tutta questa configurazione dipende dallo sforzo dello sviluppatore del plugin/componente tema nel creare una buona suite di test.
E hai ancora il problema dell’UX che dalla pagina “aggiorna” di Discourse non sai se l’ultimo job CI è fallito per una versione specifica.
Quindi, oltre ad avere un workflow di monitoraggio che ricostruisce un plugin quando il branch Discourse cambia, è necessario creare un artefatto di build che registri il risultato (pass/fail). Nei metadati del tuo plugin dovresti essere in grado di puntare a questo artefatto, e Discourse dovrebbe recuperare questo artefatto per visualizzare la compatibilità/risultato nell’interfaccia di aggiornamento.
Non è una costruzione infallibile, ma è qualcosa.