I added this line because when I added only .travis.yml it refused to build. Maybe if you create the plugin with the plugin creator that gets created automatically so this went without saying?
But adding .rubocop.yml and pushing caused my build to run when before it was just sad and gray.
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: