Ho aggiunto questa riga perché quando ho aggiunto solo .travis.yml, il processo di build si è rifiutato di partire. Forse, se crei il plugin con il generatore di plugin, questo file viene creato automaticamente, quindi era ovvio?
Comunque, aggiungere .rubocop.yml e fare il push ha fatto ripartire la build, mentre prima era solo triste e grigia.
Ouch. Quindi stanno chiudendo travis-ci.org (o almeno lo dicono), ho passato a travis-ci.com, ma mi sono esauriti i crediti del piano gratuito (https://www.travis-ci.com/plans). Non è possibile acquistare altri crediti nel piano gratuito e il piano più economico costa 69 dollari al mese. Sarei felice di poter acquistare più crediti, ma 69 dollari non sono una cifra trascurabile per me. Qualcuno ha valutato altri servizi simili?
(La guida è gravemente obsoleta; la sostituirò con una nuova)
La configurazione consigliata viene ora eseguita con GitHub Actions: consulta discourse-plugin-skeleton per un esempio.
Che peccato. Sarebbe figo se condividessi qui il metodo che usi per far prendere confidenza ai nuovi assunti con questo.
Sarebbe fantastico. Oggi ci ho passato diverse ore, anche se parte di quel tempo è andato perso a lottare per far sì che VSCode facesse la sua parte nell’aiutarmi.
Abbiamo utilizzato questa configurazione CI (quasi) per alcuni dei nostri plugin e funziona bene per gli eventi indicati.
Tuttavia, questo fallisce quando aggiungiamo un evento cron. Il motivo è che github.event non viene popolato negli eventi cron.
Quindi ora generiamo una variabile d’ambiente REPOSITORY_NAME utilizzando github.repository, che viene sempre popolata, come suggerito qui con alcune modifiche.
Ecco un esempio:
che può essere accessibile in questo modo: