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.
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
