J’ai ajouté cette ligne car lorsque j’ai ajouté uniquement .travis.yml, la construction a été refusée. Peut-être que si vous créez le plugin avec le générateur de plugin, cela est créé automatiquement, donc cela allait de soi ?
Mais l’ajout de .rubocop.yml et le push ont fait en sorte que ma construction s’exécute, alors qu’auparavant elle était simplement triste et grise.
Ouch. Donc ils ferment travis-ci.org (ou du moins c’est ce qu’ils disent). J’ai basculé vers travis-ci.com, mais j’ai épuisé mes crédits sur le plan gratuit (https://www.travis-ci.com/plans). On ne peut pas acheter plus de crédits sur le plan gratuit, et le plan le moins cher coûte 69 par mois. Je serais ravi de pouvoir acheter plus de crédits, mais 69 n’est pas négligeable pour moi. Quelqu’un a-t-il examiné d’autres services similaires ?
(Le guide est terriblement obsolète, je vais le remplacer par un nouveau)
La configuration recommandée est désormais effectuée avec GitHub Actions — consultez discourse-plugin-skeleton pour un exemple.
C’est dommage. Ce serait cool si tu partageais ici la méthode que tu utilises pour intégrer les nouveaux employés à cette démarche.
Ce serait génial. J’ai passé plusieurs heures là-dessus aujourd’hui, bien que j’aie dû lutter pour que VSCode fasse sa part du travail pour m’aider.
Nous utilisons cette configuration CI (presque) pour plusieurs de nos plugins, et elle fonctionne bien pour les événements mentionnés.
Cependant, cela échoue lorsque nous ajoutons un événement cron. La raison en est que github.event n’est pas rempli lors des événements cron.
Nous générons donc désormais une variable d’environnement REPOSITORY_NAME à l’aide de github.repository, qui est toujours remplie, comme suggéré ici, avec quelques modifications.
Voici un exemple :
qui peut être consulté comme ceci :