From: dkm@kataplop.net
To: "Mark Wielaard" <mark@klomp.org>, gcc-rust@gcc.gnu.org
Subject: Re: ☠ Buildbot (GNU Toolchain): gccrust - failed 'grep unexpected ...' (failure) (master)
Date: Tue, 10 May 2022 12:18:19 +0000 [thread overview]
Message-ID: <b55b831485459a4c9255bf98a9b8758c@kataplop.net> (raw)
In-Reply-To: <179888aa6094ad8c00dc3bb07f53695f0c5ccceb.camel@klomp.org>
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
next prev parent reply other threads:[~2022-05-10 12:18 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-10 11:00 builder
2022-05-10 11:38 ` Mark Wielaard
2022-05-10 12:18 ` dkm [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-12-09 11:17 builder
2022-12-07 15:50 builder
2022-12-07 15:47 builder
2022-11-30 10:53 builder
2022-11-07 14:09 builder
2022-10-27 19:59 builder
2022-10-26 16:25 builder
2022-10-21 16:03 builder
2022-09-30 16:21 builder
2022-09-27 7:02 builder
2022-09-27 6:49 builder
2022-08-31 10:44 builder
2022-08-25 16:37 builder
2022-08-22 15:30 builder
2022-08-19 15:07 builder
2022-08-17 12:54 builder
2022-08-09 15:36 builder
2022-08-09 15:33 builder
2022-08-09 14:53 builder
2022-08-05 13:57 builder
2022-08-05 10:37 builder
2022-08-04 20:34 builder
2022-07-22 11:58 builder
2022-07-15 17:46 builder
2022-07-15 19:18 ` Mark Wielaard
2022-07-07 10:34 builder
2022-06-01 9:33 builder
2022-05-26 9:53 builder
2022-05-26 13:15 ` Mark Wielaard
2022-05-19 10:43 builder
2022-05-11 18:06 builder
2022-05-11 18:30 ` Mark Wielaard
2022-05-10 18:05 builder
2022-05-09 11:33 builder
2022-04-28 19:48 builder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b55b831485459a4c9255bf98a9b8758c@kataplop.net \
--to=dkm@kataplop.net \
--cc=gcc-rust@gcc.gnu.org \
--cc=mark@klomp.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).