[Development] New features in CI

[Lars Knoll]

Hi all,

While the CI maintenance break today took a little longer than usual, it also came with two very nice new features that will hopefully make everybody’s life easier.

First of all, you can now find a ‘Precheck' button in gerrit. That button triggers a full CI test run of the Sha1 in the change and will post back the result of that run as a comment. This should make it a lot easier to test some of your changes before manual reviews start or at any other time when you need them. But please be aware that those runs do consume resources from the CI system, so you shouldn’t just hit that button for anything.

Secondly, we have now added a new mode on how CI integrations work. So far all changes that got staged since the last CI run would be tested together. This had the downside that we would be testing a large amount of independent changes together in one CI run. If one of those changes had a problem, all changes would get rejected. Worse, many people would then simply hit the ‘Stage’ button once again assuming it wasn’t their change that caused the problem. You probably have all experienced this in some form or another.

To fix this, we have now added a new feature (called parallel staging branches), where CI rounds are not serialised anymore. Instead, COIN will start a new CI run 15 minutes after a change (or a set of changes) got staged. It will start that run independently of whether another CI run is currently happening. If a staging branch passes, all the changes contained in that branch will be merged into the target branch (can be a fast-forward merge). If the merge produces a conflict, the staging branch will get rejected even if it passed CI.

This means that COIN will usually only test changes that are being staged together. The advantages are that you can more easily pin down a change that caused a CI failure, and that your changes will not get rejected because a buggy change got staged in the same CI run (at least it’s a lot less likely).

The one drawback is that we can in some rare cases end up with a repository in a state where two staging branches passed CI and didn’t conflict when merging them, but the merged state does not pass CI anymore for some reason. 

In that case the branch will be blocked until someone stages a fix for the problem. But we do expect this to happen rather seldom, so I do believe that the benefits far outweigh the drawback.

For now this feature is only enabled in qtbase/dev, but if it works out well, we will most likely enable it for further repositories and branches.

Last, but not least I’d like to thanks Toni Saario and Jukka Jokiniva for doing all the the hard work :)

Enjoy!
Lars