[Development] Continuous Integration for 3rd party projects using Qt

Volker Hilsheimer volker.hilsheimer at qt.io
Mon Mar 18 09:55:41 CET 2019

On 18 Mar 2019, at 07:49, Uwe Rathmann <Uwe.Rathmann at tigertal.de<mailto:Uwe.Rathmann at tigertal.de>> wrote:


thanks for the all the hints in this thread - I will check them if I
can't find a service, that is more specific:


The very first of my problems is to know about the platforms I need to
test. I guess the list of all operating system and compiler combinations
can be found somewhere in the Qt docs, but considering, that only on
"Linux" you have to consider gcc/icc/clang - for gcc only you have
v4/5/6/7/8 ...


Furthermore a project like Qwt supports all Qt versions >= 4.4. Even,
when limiting the tests to a set of relevant versions - let's say
4.8/5.6/5.9/5.12 - complexity grows significantly.


My guess is that setting up all the build environments for a) is what has
been solved with Coin. Actually I'm not interested in "continous" - it
would be good enough to compile all my stuff once in a while ?


Hi Uwe,

Great that you are considering adopting CI for Qwt.

Since you already know Linux/gcc, start from there and see what additional platforms and configurations you should add to increase your confidence that changes didn’t break anyone’s day. In the end, that’s the goal. Don’t start with shooting for 100% - there is no such thing anyway (your tests will cover those cases that you could think about when you wrote them, and there’ll always be more to learn).

Sometimes, it’s better to accept the risk that some unusual stuff breaks, as long as you (or the people impacted) can fix it quickly, than to try and build an overly complex CI monster that tries to cover all the corners but doens’t give you fast feedback loops, and is harder to maintain than the code it’s supposed to test.

In Coin, the setting up of environments is mostly done with provisioning scripts, and you can find those in qt5.git/coin. They are somewhat messy, and not easily adopted to other projects though.

To make management of environments easier and test provisioning scripts, I’m using vagrant (vagrantup.com<http://vagrantup.com>), which I drilled up quite a bit to consume provisioning mechanisms from a lot of different places. Perhaps you can use that to play around locally and to identify how your environments need to be configured, and then add the configurations that give you the most bang for the buck to a hosted CI pipeline.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190318/69adc02f/attachment.html>

More information about the Development mailing list