Enable Travis for QLC+

[peternewman]

You'll need to turn it on at http://travis-ci.org, having signed in with your Github account. It will then build all PRs.

[peternewman]

You can see what it will look like here:
https://travis-ci.org/peternewman/qlcplus/builds/53466867

I'll do a separate PR to add other plugins like OLA.

[peternewman]

I've had to turn off the Clang builds, as -Wno-unused-local-typedefs causes errors with Clang. Is there some way that can be overriden by the build or by compiler, rather than just not using it on OS X?

[mcallegari]

Can you please explain the advantages of having this ?

I'm not sure if a CI system has any sense on GitHub since there's no voting system for a PR here.
The Qt project works with Gerrit and developers can review/upvote/downvote a patch. When it's committed to be merged the CI gives its results and decide if the patch is ok for integration or not.

[peternewman]

It means you know that all code merged in via PRs passes all the tests before its merged.

Within OLA, we've also extended it to run lint and doxygen checks on the code. For example when I tried to commit some invalid doxygen, it reports it within the PR and you can see the details (.e.g https://travis-ci.org/OpenLightingProject/ola/builds/49820244 ). For an example with actual invalid code see OpenLightingProject/ola#574 . The cross and tick represent the build state.

It's the same idea as Qt from the sounds of things, just in the opposite order. Rather than you waste your time reviewing broken code, you can see if the code compiles, the tests pass and any other criteria are met before you spend time looking, and otherwise potentially spotting the lint issues and bugs yourself and asking the user to fix them.

Within OLA, we also use buildbot, across a broader range of machines/OSes, but that only tells you broken code exists after it's been merged.

This bug is what kicked it off for me OpenLightingProject/ola#657 . Using Travis you can get it to build each PR/commit potentially against gcc, clang on Linux (there's also mention of OS X too) and both qmake 4 and 5 if you wanted. Which is something a single developer/contributor can't easily do, even if they're dedicated enough to want to.

@nomis52 will also back me up, as he's a big fan of it too.

[nomis52]

What Peter said. In the OLP we don't look at pull requests until the CI system is green.

[mcallegari]

OK guys, you conviced me 😃
Let's try this out and see how it goes.

Thanks for this and for making me discover another new geeky thing ! 👍

[mcallegari]

So I've enabled the build in Travis. Now I've got a few questions:

• I see it's a debian based build. I would be interested in testing also: Linux/Qt5, Slackware, OSX (for any clang related issue, see QLC+ OLA plugin build issue OpenLightingProject/ola#657). Is that possible ?
• the OLA plugin doesn't get built
• I don't see the existing PR listed in the Travis website. How do I sync and test them ?
• when I receive a PR, will Travis automatically test it or should I do it manually ?
• is there any way to pull test builds from Travis ? Kind of using it like a "nightly build" service ? This would be interesting for users wanting to test a specific PR

Thanks !

[EDIT] Apparently OSX builds are possible: http://docs.travis-ci.com/user/osx-ci-environment/
But it seems they don't accept multiple builds ATM: http://docs.travis-ci.com/user/multi-os/

[peternewman]

Excellent @mcallegari you've made the right choice. :)

Although I note the build is now failing with a test issue:
https://travis-ci.org/mcallegari/qlcplus/builds/53796263
Which appears to be around:
#455

We can build Qt5 on Linux and clang on Linux (if you can provide some way to not pass in -Wno-unused-local-typedefs as a compiler flag when using Clang on Linux, perhaps a command line flag). Travis can only build on the OSes it supports, so Debian and OS X

I should be able to make the OLA plugin build, ideally from source, or the debs if not.

The existing PRs need a new commit pushed to them to make them build, getting people to resync with trunk should be sufficient (but without reading the build log, the broken build due to #455 will just muddy the waters at the moment.

Travis will run automatically against PRs if you turned that on in it's settings.

I'm not aware of any way to extract files from Travis. We use buildbot too ( https://buildbot.openlighting.org/waterfall ) and it's on my todo list to make the build slaves make nightly debs.

[peternewman]

Sorry, I was misreading the logs, #455 is an excellent example, it's an open pull that's currently failing the tests.

Another thing you can do, I see you have have the option to generate code coverage, you can also use https://coveralls.io/ to check code coverage as part of the Travis build. Our coverage info looks like this: https://coveralls.io/r/OpenLightingProject/ola

[mcallegari]

So, #455 is failing the tests. I've seen now the Travis intervention saying "Merge with caution" 😄
I am interested in clang only for OSX. I don't think there are users building with clang on Linux.
Would you help me to setup the Travis build also for OSX/clang and Linux/Qt5 ?
That would help me to spot much more compiler-related issues.

As for buildbot, unfortunately QLC+ doesn't have webhosting (still using SourceForge...but I am really sick with it) so when I'll move away I'll consider to setup an automated process like you guys did.

Thanks !

[peternewman]

I don't think there are people building on Clang for Linux either @mcallegari but I think it provides something equivalent and should at least catch the OS X compiler messages. If you can get your project signed up for OS X on Travis, then great, we can do that. Otherwise the Clang offer still stands if you want (as it's just a case of rehashing what we have for OLA).

Qt5 should be fine.

Probably more a question for @nomis52 or the people hosting the slaves as a whole, but I don't think there's any technical limitation to either hosting a second Git repo within our buildbot master, or running a second master on the same machine. It may even work in our favour, if you can get some members of the QLC+ community to host slaves, it can either share out the workload of the existing OLA slaves, while building both bits of software, or offer more diversity of testing across a range of OSes if people have Slackware and similar as you mentioned.

[kripton]

Just FYI: I have a build slave running for OLA (ODROID U2, ARMv7) and I wouldn't mind building qlcplus on that machine, too. clang wouldn't be a problem, Qt5 should also be possible.

[nomis52]

Yeah we can certainly start up another buildmaster for QLC on the VM and add slaves to it. We have a mac mini and Ubuntu Tahr machine we can add. I've created https://github.com/OpenLightingProject/qlc-buildbot to host the configs. I'll try to setup the VM side this week.

[peternewman]

You want to run it as an entirely seperate buildmaster then @nomis52 ? I've moved it to https://github.com/OpenLightingProject/qlcplus-buildbot to avoid any confusion...

[mcallegari]

Wow guys, this looks fantastic !
I need to read a bit more about buildbot, as I could probably offer some slaves too.
I've got Ubuntu 12.04 32bit, Ubuntu 14.04 64bit, Mint 17.1 64bit, OSX 10.10, Windows 7 64bit, Raspberry Pi 1, Raspberry Pi 2, Odroid C3, pcDuino 3 😄

My only problem ATM is that I have almost no time to dedicate to this, so I am really appreciating your contribution !
If there is anything I can do to help, please let me know and I'll find the time for it.

[peternewman]

Thinking about this @nomis52 if we run a seperate master, people will have to run two slaves on each machine to connect to the two masters. Is all the hassle worth it for the bit of seperation of output it gives us? Through the config they wouldn't have to run builds against both if they didn't want to.

@mcallegari that's an impressive selection of hosts. Would you be willing to get some of those building against OLA too once we've done the leg work for your buildmaster? If you're curious, here's our info on setting up a slave, the process for a QLC+ one will be fairly similar, aside from the selection of packages to be installed.

[mcallegari]

@peternewman should I read this: https://wiki.openlighting.org/index.php/OLA_Buildbot ?

What's the deal with buildbot ? Once configured it starts automatically when the host is online or do I have to start it manually ?
If so, within the embedded devices that I've got, the Rpi 2 is the one I turn on most frequently.
As for PCs, Mint is almost always online. The others need to be started "on demand" (even though I find myself playing pretty frequently on Windows lately... 😖 )

[mcallegari]

Please continue the discussion on #463
(found it awkward to discuss on closed PRs 😄 )
Thanks