(Superseded) Set up plugin continuous integration tests on Travis CI

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.

1 Like

Ouch. So they’re closing down travis-ci.org (or so they’ve been saying), I switched to travis-ci.com, but I ran out of credits on the free plan (Travis CI - Test and Deploy with Confidence). You can’t buy more credits on the free plan, and the cheapest plan is $69/month. I’d be happy to be able to buy more credits, but $69 is not inconsequential for me. Has anyone looked at any other such services?

1 Like

(The guide is woefully outdated, I’ll be replacing it with a new one)

The recommended setup is now done with GitHub Actions - see discourse-plugin-skeleton for an example.

5 Likes

That’s a bummer. It’d be cool if whatever means you get new hires on board with this was shared here.

That would be awesome. I’ve spent several hours on this today, though some of that was fighting with getting vscode to do its part in helping.

We’ve been using this(nearly) CI setup for a few of our plugins it works well for the said events.

But this fails when we add a cron event. The reason being, github.event is not populated on cron events.

So we now generate an environment variable REPOSITORY_NAME using github.repository which is always populated as suggested here with some modifications.

Here’s an example

which can be accessed like this.

2 Likes