[Development] New features in CI

Oswald Buddenhagen oswald.buddenhagen at gmx.de
Mon Mar 1 17:53:32 CET 2021


On Mon, Mar 01, 2021 at 04:22:01PM +0000, Edward Welbourne wrote:
>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.
>
that's true, but otoh the build branch contains real commits that can be 
viewed on gerrit itself. if somebody bothered to implement auto-linking 
(just steal the compiler output parsers from qt creator) that would be 
even easier to use (esp. for others than the owner) than accurate line 
numbers.

> Oswald Buddenhagen (1 March 2021 17:02) replied:
>> 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.
>
yeah, but it occurs to me that post-integration rebases mess up the 
linking of sha1s to ci results. the system would have to rewrite the 
logs post-integration.

>> 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.
>
no, but you are conflating two independent process parameters. it's 
perfectly possible to keep a separate manual trigger for the 
authoritative builds, which would trigger auto-integration upon success.
the applied integration/merge strategy may still require a custom 
modification.


More information about the Development mailing list