Ti invito a condividere pensieri su possibili flussi di lavoro CI, che eseguirebbero test su plugin non ufficiali forniti dalla community.
Alcune community dipendono fortemente da plugin, senza manutenzione consolidata:
Poiché il testing dei plugin dipende da un’installazione di Discourse come banco di prova, mi chiedo come potrebbe apparire un flusso di lavoro CI supportato dalla community.
Alcuni plugin includono specifiche, come l’implementazione di @angus di activitypub, che, a quanto ho capito, abilita i test per la CI.
Attualmente, penso a due possibili modi per migliorare il testing dei plugin non ufficiali, a seconda delle specifiche / test, inclusi nel codice sorgente del plugin:
a) costruire qualche meccanismo, che aiuti i manutentori del sito a eseguire test in un ambiente di staging
b) avere un servizio, che esegua il fork di un’immagine di test predefinita per segnalare i test eseguiti sull’ultimo codice pubblicato del plugin.
Cosa ne pensi?
Ho perso qualche flusso di lavoro già consolidato?
Oltre alla CI con test di backend e frontend, che la maggior parte dei plugin Pavilion ha ormai, disponiamo di un sistema di gestione dei plugin di cui la CI è una parte. Ecco come funziona
Che visualizza lo stato dei controlli per la compatibilità dei plugin Pavilion (e talvolta altri) rispetto a tests-passed e stable. Questo viene aggiornato ogni giorno, automaticamente.
Questo ovviamente si basa sui test, inclusi smoke test, spec (backend) e test qunit (frontend).
Il nostro plugin in abbonamento (Custom Wizard) ha la massima copertura di test, come puoi immaginare, ma alcuni dei nostri plugin gratuiti includono una buona suite di test sia backend che frontend (ad esempio, Locations).
Scrivere test è una buona pratica e certamente Pavilion è diventato ancora più disciplinato in questo settore man mano che siamo maturati come azienda.
Fondamentalmente, i test documentano anche la tua funzionalità prevista, il che è estremamente importante soprattutto durante gli aggiornamenti di compatibilità o il refactoring.
È un’architettura secondo il diagramma di @angus, con più repository coinvolti, ma questo è il server di stato:
È anche un approccio:
Non implementare mai una correzione senza verificare la presenza di un test e, se un test idoneo non esiste, aggiungerne uno.
Preferibilmente sviluppare prima il test, dimostrare che fallisce, quindi correggere il problema e confermare che il nuovo test passa.
In questo modo la tua copertura aumenta nel tempo…
Inoltre:
L’adeguamento retroattivo dei test può essere rischioso poiché potresti interpretare erroneamente ciò che il codice intendeva fare… meglio che non fare nulla, però…
Tutti i plugin ufficiali hanno specifiche che puoi usare come esempi. Il plugin discourse-plugin-Skelton include github Actions per eseguire test a ogni commit e, credo, quotidianamente.
a) Questo è disponibile tramite GitHub actions: i plugin con specifiche / test appropriati utilizzando GitHub actions avranno un badge su GitHub, se tutti i test passano e lo stato delle azioni CI è leggibile da API.
b) Ad eccezione dei plugin ufficiali di discourse e dei plugin pavilion, non esiste una panoramica automatica per gli amministratori, se i plugin utilizzati funzioneranno nella versione prevista per l’aggiornamento?
Per quanto ho capito, questa è una soluzione al problema inverso: discourse troppo vecchio per un plugin.
Come trattare l’altro caso: plugin troppo vecchio per discourse?
Potrebbe /admin/upgrade avvisare riguardo ai plugin, che falliscono i test per un aggiornamento previsto?
In origine ci eravamo prefissati di fornire una versione non brandizzata della nostra dashboard dei plugin, dove autori di terze parti potessero presentare i loro plugin per l’inclusione. Questo non ha avuto successo, in parte perché la popolazione di sviluppatori di plugin di terze parti è davvero molto piccola.
La creazione di plugin di terze parti per Discourse è piuttosto di nicchia e la fornitura di plugin con una buona copertura di test da parte di terzi è molto di nicchia!
Molti dei freelance in questo settore si sono uniti a Pavilion o CDCK (o, col tempo, a entrambi!)
Quindi, alla fine, abbiamo deciso di integrare la nostra dashboard nel nostro sito community brandizzato.
