To set up continuous integration for your plugin, you can use our discourse-plugin-ci repository. This will run the Discourse core linters (prettify, eslint & rubocop), your plugin’s Rspec tests, and your plugin’s Qunit tests.
Once you’re signed in, go to your profile page and enable builds for your plugin
And that’s it! Every time you make a commit or a PR, tests will be run against the tests-passed version
To make sure that new discourse releases don’t break your plugin, you can try setting up Travis’s CRON to run the tests every day, regardless of whether you’ve changed the plugin. My setup looks like this:
Ideally I don’t want to allow_failure on any of the 3 release branches. Unfortunately the stable branch of discourse currently fails its own tests (see all the red crosses here) and has been failing since at least 6th Feb. That’s kinda ironic since it’s supposed to be the stable branch
Getting plugin CI tests working on travis is now super easy with the recent changes to the docker_test rake task. I’ve update the gist in my top post. discourse-chat-integration currently takes about 3.5 mins to load the image, setup, run rspec tests & qunit tests, so pretty quick by travis standards.
@team could someone please make the top post a wiki so I can update it? Also, would you accept PRs to add travis to official plugin repos?
Sorry to keep peppering you with questions, but I’ve found that when a plugin includes a gem, like my locations plugin does, gem install [gem] will throw a permissions error when Discourse attempts to install it in the Docker container. Any thoughts on how to set the permissions right inside the container?
Because we’re mounting the plugin code as a volume in the docker container, it gets all of its permissions/owner/group from the host system (travis). The UID of the travis user, and the UID of the “discourse” user inside the container are not the same, and so the discourse container does not have write access to the plugin directory.
I would never recommend this in a production system, but since this is just tests, I think it is safe to do a chmod -R 777 on the plugin files before running the tests. I wouldn’t call it a fix, but it does work around the problem.
I submitted a PR to your repo with the 1 line fix, which works for travis builds on my fork
I’ll add a note to the OP here in case anyone else has the same issue
The measuring of coverage itself is a bit quirky. Presumably because of the order in which files are loaded, any code executed in plugin.rb doesn’t get picked up by simplecov. I’m sure there’s some way around this, but I haven’t been able to figure it out (and I’ve just got around the problem by moving all the code I can into separate files).
To actually get coverage running, I import this file at the top of all my specs:
Which relies on those gems being installed, which I achieve like so:
It would be to see support for this in core. There’s a smattering for some of it already:
Happy to submit a PR incorporating some of these improvements upstream, but I’ll take guidance on which would be welcomed.
Also, if anyone has any ideas about how to check JS test coverage that would be welcomed by me! There seemed to be a few methods of getting LCOV-formatted data out of QUnit-run tests, but none seemed to slot nicely into our existing tooling.
Amazing! Glad my work was a useful starting point, but it sounds like you’ve made it a lot better!
I like the system you have for keeping all the travis stuff in a separate repo, rather than having to copy the .travis.yml file around. It would be nice to have an ‘official’ version of this for plugin developers to use (and for us to use in core plugins).
Cool! I had no idea you could control the folding just by echoing a string! A pull request to add this would be welcome, as long as it is behind an ENV variable.
This is interesting, I think it’s probably worth starting a new topic to discuss any core changes that would be useful for coverage reporting.