Re: ☠ Buildbot (GNU Toolchain): gccrust - failed 'grep unexpected ...' (failure) (master)

[dkm@kataplop.net]

May 10, 2022 1:38 PM, "Mark Wielaard" <mark@klomp.org> wrote:

> On Tue, 2022-05-10 at 11:00 +0000, builder--- via Gcc-rust wrote:
> 
>> A new failure has been detected on builder gccrust-debian-i386 while
>> building gccrust.
>> 
>> Full details are available at:
>> https://builder.sourceware.org/buildbot/#builders/27/builds/98
> 
> Just when we were all green :{
> 
> It isn't clear to me what bors is doing though. It seems to just throw
> in commits randomly and then tries to fix things up with a merge
> commit.
> 
> Is there any way to make bors not do that? It makes the buildbot
> unhappy and makes bisecting commits really hard.
> 
> Ideally all commits are done on top of the tree without these odd merge
> commits. So do a simple rebase first, then commit/push.
> 

I don't think that's possible. I recall reading that bors-ng handles it this way and you can't change this behavior. It tests everything waiting in the queue and only split this if tests are KO:

https://github.com/bors-ng/bors-ng

"
As commits are reviewed, bors lumps them into a queue of batches. If everything passes, there will just be two batches; the one that's running, and the one that's waiting to be run (and is accumulating more and more pull requests until it gets a chance to run).

To run a batch, bors creates a merge commit, merging the main branch with all the pull requests that make up the batch. Instead of pushing the merge commit immediately, however, it will instead push it to the staging branch. They'll look like this:

Merge #5 #7 #8

5: Rename `bifurcate()` to `bifurcateCrab()`
7: Call `bifurcate()` in the `onland` event handler
8: Fix crash in `drive()`

If the build passes, the main branch gets fast-forwarded to meet the staging branch. Since the main branch contains the exact contents that were just tested, bit-for-bit, it's not broken. (at least, not in any way that the automated tests are able to detect)

If the build fails, bors will follow a strategy called "bisecting". Namely, it splits the batch into two batches, and pushes those to the queue. In this example, the first batch will look like this:
...
"

:(

Marc