Adding continuous integration support to JUCE with TravisCI

General JUCE discussion
1

Working JUCE-based project examples:

  • https://github.com/jrlanglois/drowaudio/blob/master/.travis.yml
  • https://github.com/jrlanglois/jrl_acc/blob/master/.travis.yml
  • https://github.com/jrlanglois/drowaudio/blob/master/README.md
  • https://github.com/jrlanglois/jrl_acc/blob/master/README.md

Example from my JUCE fork (https://travis-ci.org/jrlanglois/JUCE) (WIP for MacOSX support)

  • https://github.com/jrlanglois/JUCE/blob/master/.travis.yml
  • https://github.com/jrlanglois/JUCE/blob/master/README.md

Please consider implementing this travis configuration into the official repository.

I've set it up to compile the UnitTestRunner on the default installations of Clang (v3.5.0) and GCC (v4.8.4).

Additionally, I've fixed up the README file to be of extension .md, and added the TravisCI build status to it: https://github.com/jrlanglois/JUCE

Note that the configuration rightly builds the unit tests with the 3 UTF formats, something I strongly believe is long overdue. (This post feels like so yesterday now: http://www.juce.com/forum/topic/error-compiling-jucestringutftype32 )

There are caveats to using TravisCI. The major ones I can think of is not being able to easily test plugin hosting and generation (VST2/3/AudioUnit/RTAS/AAX), and not being able to test on Windows.

2

I think it would be great if JUCE used CI!

Currently when merging my JUCE branch I’ve wasted some time and effort on the Projucer not compiling for two commits starting at 3f2f2f6.

Using CI to automatically check pull requests and branches would catch many such things before they are pushed to the main branch and would make things more stable.

3

IIRC they are using Jenkins

4

Roli uses Jenkins, based on comments I recall from the forums. And yep, I agree that more stuff would be caught in the CI… Seeing that none of that is made public (for whatever reason?), it’s tough to specifically suggest anything that could be done differently.

I don’t know what their scripts do, but I would love to see code coverage and that sort of thing. Among more elaborate automated testing schemes.

5

We do use CI - each commit to the develop and master branches is tested.

The broken commit that you linked was my bad, it was part of a large change with the following commit and I thought it was clearer to split them up into two - I didn’t expect it to cause an issue. It wasn’t picked up by our CI because both commits were done at the same time, and the CI built the latest.

6

@ed95 Curious question - do you run the unit tests with the various possible configurations from the codebase?

For example:

7

Currently no, that’d be a nice addition though.

8

If I understand correctly - it’s checked after it is pushed to the main branch? If so, I think it might be preferable if the CI would test the commit in the feature branches, before it is ever pushed to the main branch, so that the main branch is valid at all times.

9

No, we have a private mirror where we test features and bug-fixes and once they have passed the CI tests then the commits make their way onto the public branches. The commit that you linked was part of a larger feature branch which passed the CI tests and I squashed it to 2 commits.

2 Likes
10

+1 to that

There’s a Jenkins plugin for GitHub to build PRs prior to merging - blocking them from merging unless all jobs succeed… It would mean an extra step on the internal fork of JUCE, within the Roli team, but I think it’s worth it.

This would be the exact same set up I use at my work, actually. It works super well, especially since we have to support a dozen platforms.

1 Like