Am 01.03.21 um 14:25 schrieb 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.
Will the CI autodetect such a situation? Will it create a suitable alert?
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
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development