On Mon, Mar 01, 2021 at 01:25:50PM +0000, Lars Knoll wrote:
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.
so this simply exposes the pre-existing functionality. that means that
testing a change accurately requires always rebasing it, which is
exactly the opposite of the usual recommendation to not rebase unless
conflicts occur. the system should instead create a build branch which
is simply a rebase of the chosen sha1 (incl. its ancestors) to the tip
of the target branch.
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).
you mean actual git merges, rather than rebases/cherry-picks? that will
lead to a completely insane history in busy repositories.
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.
if you accept that, there is no point in the custom CI gate in the first
place - just assign a required review label to the CI system like almost
every other project in the world does.
also, rather than sinking more and more resources into coin, you should
have a look at zuul, which is a very gerrit-centric CI with a much
better feature set and an actual community around it.
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
