[Development] New features in CI

[Edward Welbourne]

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.

Oswald Buddenhagen (1 March 2021 17:02) replied:
> so this simply exposes the pre-existing functionality.

A bit better packaged than the internal form used to be, but yes.

> 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.

Given that Gerrit now keeps track of +1s and +2s when rebases are clean,
the pain due to rebases is significantly reduced these days. It still
fills up mail-boxes, of course, but the old recommendation is at least
somewhat less critical than it used to be.

And, as ever, do not let the craving for perfection be a reason against
accepting an improvement. One advantage of testing the branch as it
stands in Gerrit, rather than a rebase of it, is that line numbers in
the resulting build report will really correspond to those in the commit
tested, without random perturbations due to changes the branch was
rebased onto.

>> 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.

I'm a bit curious about that one myself; but it can perfectly well be
implemented as a rebase, after all.

>> 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.

You're taking for granted your earlier demand that the system be
reworked to test a rebased version of the branch.  Without that, there
remains value in a separate CI gate.

	Eddy.