"
- discourse-plugin-ci/script.sh
```
---
### Author:  [@vinothkannans](https://meta.discourse.org/u/vinothkannans)
#### Post date: [March 21, 2017, 1:02pm UTC](https://meta.discourse.org/t/superseded-set-up-plugin-continuous-integration-tests-on-travis-ci/59612/2 "2017-03-21T13:02:20Z")
Can you please tell why you allow\_failure on stable branch instead of beta branch?
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [March 21, 2017, 1:14pm UTC](https://meta.discourse.org/t/superseded-set-up-plugin-continuous-integration-tests-on-travis-ci/59612/3 "2017-03-21T13:14:33Z")
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](https://github.com/discourse/discourse/commits/stable)) and has been failing since at least 6th Feb. That’s kinda ironic since it’s supposed to be the **stable** branch 😉
So once that’s fixed I’ll turn off `allow_failure`
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [July 21, 2017, 11:41am UTC](https://meta.discourse.org/t/superseded-set-up-plugin-continuous-integration-tests-on-travis-ci/59612/4 "2017-07-21T11:41:22Z")
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.
[https://gist.github.com/davidtaylorhq/0c73c93af68724ffbd47f18eff7fbb12](https://gist.github.com/davidtaylorhq/0c73c93af68724ffbd47f18eff7fbb12)
[@team](https://meta.discourse.org/groups/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?
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [September 5, 2017, 6:54am UTC](https://meta.discourse.org/t/superseded-set-up-plugin-continuous-integration-tests-on-travis-ci/59612/5 "2017-09-05T06:54:39Z")
@david This script didn’t work for me out of the box. Is there any other config it assumes?
It fails in Travis with
```
The command "docker run -e "COMMIT_HASH=origin/tests-passed" -e "SKIP_CORE=1" -e SINGLE_PLUGIN=$plugin_name -v $(pwd):/var/www/discourse/plugins/$plugin_name discourse/discourse_test:release" exited with 1.
```
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [September 5, 2017, 8:52am UTC](https://meta.discourse.org/t/superseded-set-up-plugin-continuous-integration-tests-on-travis-ci/59612/6 "2017-09-05T08:52:37Z")
Hmmm… I don’t think there should be anything required beyond the Travis config above.
There’s a working config on discourse-chat-integration: [Travis CI](https://travis-ci.org/discourse/discourse-chat-integration/jobs/271692470)
Do you have a link to a failing Travis job you can spare?
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [September 5, 2017, 8:55am UTC](https://meta.discourse.org/t/superseded-set-up-plugin-continuous-integration-tests-on-travis-ci/59612/7 "2017-09-05T08:55:56Z")
Yup: [Travis CI](https://travis-ci.org/angusmcleod/discourse-elections)
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [September 5, 2017, 9:00am UTC](https://meta.discourse.org/t/superseded-set-up-plugin-continuous-integration-tests-on-travis-ci/59612/8 "2017-09-05T09:00:55Z")
Looks like it’s failing at the rubocop linting stage - roughly line 710 in the log.
If you don’t want to lint the code, and just run tests, you can add `-e SKIP_LINT=1` to the docker run command.
All the environment variables available are listed at the top of docker.rake:
>
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [September 5, 2017, 9:07am UTC](https://meta.discourse.org/t/superseded-set-up-plugin-continuous-integration-tests-on-travis-ci/59612/9 "2017-09-05T09:07:50Z")
Ah. I had assumed they were warnings rather than errors that would stop the script. Thanks for taking a look.
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [September 5, 2017, 9:10am UTC](https://meta.discourse.org/t/superseded-set-up-plugin-continuous-integration-tests-on-travis-ci/59612/10 "2017-09-05T09:10:54Z")
No problem 🙂
The docker script is designed to “fail quickly” - if any of the steps fail, it will exit with an error, and won’t bother with the rest of the steps.
This is good from an efficiancy point of view, but it can get quite annoying when debugging!
The length of the logs it produces is also obscene, which doesn’t help 😖
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [September 20, 2017, 3:36am UTC](https://meta.discourse.org/t/superseded-set-up-plugin-continuous-integration-tests-on-travis-ci/59612/11 "2017-09-20T03:36:32Z")
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?
See: [Travis CI](https://travis-ci.org/angusmcleod/discourse-locations)
Note that `lib/plugin_gem.rb` handles the installation of plugin gems (I think).
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [September 20, 2017, 4:02pm UTC](https://meta.discourse.org/t/superseded-set-up-plugin-continuous-integration-tests-on-travis-ci/59612/12 "2017-09-20T16:02:51Z")
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](https://github.com/angusmcleod/discourse-locations/pull/1) to your repo with the 1 line fix, which [works](https://travis-ci.org/davidtaylorhq/discourse-locations/builds/277829578) for travis builds on my fork 🙂
I’ll add a note to the OP here in case anyone else has the same issue
---
### Author:  [@LeoMcA](https://meta.discourse.org/u/LeoMcA)
#### Post date: [August 17, 2018, 2:32pm UTC](https://meta.discourse.org/t/superseded-set-up-plugin-continuous-integration-tests-on-travis-ci/59612/13 "2018-08-17T14:32:31Z")
@david thanks so much for the comprehensive post, it helped immensely when getting my own plugin’s specs running in Travis ❤
Here’s an example: [Travis CI](https://travis-ci.org/mozilla/discourse-mozilla-iam), and the scripts common to all my plugins live in:
[https://github.com/mozilla/discourse-mozilla-travis](https://github.com/mozilla/discourse-mozilla-travis)
From implementing this (and banging my head against my desk a lot) I’ve got a few improvements to propose:
## Extract plugin name from `plugin.rb`
We have a discrepancy between the name of our plugins (e.g. `mozilla-iam`) and the name of its repo (e.g. `discourse-mozilla-iam`).
So I came up with a little oneliner to extract that name from `plugin.rb` rather than the directory:
>
(some extra escapes will have to be thrown in to put it in a `.travis.yml`)
## Travis log folding
> [@david](#):
>
> The length of the logs it produces is also obscene, which doesn’t help 😖
Like Travis does automatically with all the pre-`install` and pre-`script` gubbins, you can force Travis to fold a section of output by echoing `travis_fold:start:#{id}` and `travis_fold:end:#{id}`
So like:
```plaintext
echo "travis_fold:start:discourse_setup"
```
and
```plaintext
echo "travis_fold:end:discourse_setup"
```
I did however spend far too long getting this working, because I managed to misspell discourse in the end command without noticing 😑
To actually wrap the relevant sections with that command I had to roll my own near-duplicate of [discourse/lib/tasks/docker.rake at main · discourse/discourse · GitHub](https://github.com/discourse/discourse/blob/master/lib/tasks/docker.rake).
I’d propose that script `puts` some fold commands if [`TRAVIS=true`](https://docs.travis-ci.com/user/environment-variables/#default-environment-variables).
# Measure code coverage and export to Coveralls
This is probably the least supported thing I got _kinda_ working, and probably requires further discussion in its own topic.
It can be seen in practice here: [mozilla/discourse-mozilla-iam | Coveralls - Test Coverage History & Statistics](https://coveralls.io/github/mozilla/discourse-mozilla-iam)
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:
>
But simplecov isn’t in the Gemfile.
To then get coverage exported to Coveralls, I [needed to export a couple of environment variables to docker](https://docs.travis-ci.com/user/coveralls/#using-coveralls-with-docker-builds).
* * *
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.
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [August 17, 2018, 3:00pm UTC](https://meta.discourse.org/t/superseded-set-up-plugin-continuous-integration-tests-on-travis-ci/59612/14 "2018-08-17T15:00:00Z")
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).
> [@LeoMcA](#):
>
> To actually wrap the relevant sections with that command I had to roll my own near-duplicate of [discourse/docker.rake at master · discourse/discourse · GitHub](https://github.com/discourse/discourse/blob/master/lib/tasks/docker.rake).
>
> I’d propose that script `puts` some fold commands if [`TRAVIS=true`](https://docs.travis-ci.com/user/environment-variables/#default-environment-variables).
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.
> [@LeoMcA](#):
>
> Measure code coverage and export to Coveralls
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.
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [September 13, 2018, 5:23pm UTC](https://meta.discourse.org/t/superseded-set-up-plugin-continuous-integration-tests-on-travis-ci/59612/20 "2018-09-13T17:23:35Z")
I’ve now set up an ‘official’ repository for testing plugins on travis. The instructions above have been updated accordingly.
I have also added the Travis ‘log folding’ to our `docker.rake` task, so the travis logs are much nicer to read. The 9000 line log now folds down to this
---
### Author:  [@Machigatta](https://meta.discourse.org/u/Machigatta)
#### Post date: [November 21, 2018, 2:05pm UTC](https://meta.discourse.org/t/superseded-set-up-plugin-continuous-integration-tests-on-travis-ci/59612/21 "2018-11-21T14:05:23Z")
Somehow the SKIP\_LINT enviroment variable is not working i guess..
even though it’s setting the variable
cause it’s still running in the building/testing process
even after terminating all the lint-errors the build is still exiting with 1 :notsureif:
The only error i’ve found so far is that prettier exiting with a 1 as well
> **[Travis CI](https://app.travis-ci.com/kokoro-ko/discourse-humble-box/builds/457954010)**
>
> Travis CI enables your team to test and ship your apps with confidence. Easily sync your projects with Travis CI and you'll be testing your code in minutes.
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [November 21, 2018, 2:09pm UTC](https://meta.discourse.org/t/superseded-set-up-plugin-continuous-integration-tests-on-travis-ci/59612/22 "2018-11-21T14:09:37Z")
Good catch, I’ve fixed it here:
[https://github.com/discourse/discourse-plugin-ci/commit/006082b794bb560adaa7f9a5e0925ab5aa79e3e1](https://github.com/discourse/discourse-plugin-ci/commit/006082b794bb560adaa7f9a5e0925ab5aa79e3e1)
If you restart your travis job it should work now 🙂
---
### Author:  [@Machigatta](https://meta.discourse.org/u/Machigatta)
#### Post date: [November 21, 2018, 2:17pm UTC](https://meta.discourse.org/t/superseded-set-up-plugin-continuous-integration-tests-on-travis-ci/59612/23 "2018-11-21T14:17:54Z")
Oh well yea thank you very much. Now my build is passing 🙂
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [November 21, 2018, 2:20pm UTC](https://meta.discourse.org/t/superseded-set-up-plugin-continuous-integration-tests-on-travis-ci/59612/24 "2018-11-21T14:20:33Z")
Glad to hear it. I guess you are already aware - but just in case: you have no tests, and you have now disabled linting. So the travis build is checking… nothing 😉
---
### Author:  [@Machigatta](https://meta.discourse.org/u/Machigatta)
#### Post date: [November 21, 2018, 2:21pm UTC](https://meta.discourse.org/t/superseded-set-up-plugin-continuous-integration-tests-on-travis-ci/59612/25 "2018-11-21T14:21:41Z")
Yea i am aware of that. Tests are following now, after the basic travis.ci is running without linting and prettier 😃
Tests won’t run with blocking testers 😄
[Next page](https://meta.discourse.org/t/superseded-set-up-plugin-continuous-integration-tests-on-travis-ci/59612.md?page=2)