Proposal: move to bors-ng

[Eh2406]

Indeed parallel building is the best way to speed up testing and leave the artifacts intact. This Is best described in the documentation for zuul. But as alexcrichton pointed out “Right now we unfortunately just don’t have capacity”.

The discussion on adding procedurally generated rollups to the existing infrastructure is at homu/issues/102. Although sofar it is mostly me working conceptually. I would love to hear what people are concerned about and what strategies they would or would not find acceptable.

Also one day I’d love to see this in rust, but those projects are still pretty far off.

[ishitatsuyuki]

I still find that automatic rollup would be much better, because:

• It’s hard to predict whether a PR is 100% safe or not. We have oversights.
• PRs get rolled up all times. This means that we can stay at a relatively idle state, avoiding the rollup mistakes when the queue gets filled with too much PRs (pressure) that can potentially fail.

But well, @notriddle I found the lack of priority a blocker for migration. Let’s get it implemented soon. bors-ng is really well maintained

[brson]

The described batching algorithm does seem like it has a high potential to not work well for Rust, with our long turnaround times, and high intermittent rates. I’d be more comfortable adopting it if it supported our existing workflow and let us gradually experiment with others.

If bors-ng is going to be maintained, and it can support our workflow, and somebody is willing to do the work of the transition, and preferably if it can remain under the venerable ‘bors’ account, then it might be worth pursuing. We’ve long wanted to replace homu. I’m glad somebody has finally done the work - I didn’t realize it was ongoing.

Here’s what it looks like in action: https://bors-app.herokuapp.com/

Sadly there’s no activity in the queue.

[brson]

Also re the batching algorithm, we often use bors in ways where we probably don’t want batching. For example, just last week I threw a PR at bors several times, fully expecting it to fail, just so I could see what the CI windows results would be.

[brson]

It would be prudent to identify our current bors wishlist, and see how bors-ng will address them. We’ve often discussed changes to homu we want, but don’t make because nobody wants to hack on homu.

[notriddle]

• Every repository gets it’s own queue.
• Right now, the front dashboard page only shows repos that you have reviewer permissions for. That’s not going to change: on the public bors-ng instance, where anybody can add their repo, a global “awaiting review” list would be too long.
• Right now, the individual repo pages are only accessible to reviewers. That shouldn’t be hard to fix, by providing a sort of “read only” mode when non-reviewers open them.
• From an admin’s POV, I can see that there’s webhooks hits every single day. I should probably set up a public metrics collector?
• Right now, my main concern is fixing the hit-by-a-bus factor. I assume this would be a high priority for Rust, as a potential user.

[notriddle]

Here’s an example of what it looks like in RO mode. The PR to enable this is in review, now.

Edit: PR landed and deployed. Here’s the queues for:

• bors-ng/bors-ng
• intellij-rust/intellij-rust
• nix-rust/nix
• georust/rust-geo

[eminence]

In the context of finding enough people who know the language and are willing to improve the bors-ng codebase, is the usage of elixir expected to be a benefit, a detractor, or neutral?

[notriddle]

Compared to Rust, I expect it to be neutral as far as finding developers. Compared to Python, however, it probably makes it harder to find developers.

[Eh2406]

I am working on understanding how homu works so I can hack on it. I am starting with batching, I am trying to design something very small and conservative to start with.

If we have a wishlist, then let’s get it together so persons can help.

As bors-ng seams better maintained, when it meets most of the requirements then I’d advocate for the switch. Not that I have much say in the matter.

[notriddle]

But well, @notriddle I found the lack of priority a blocker for migration. Let’s get it implemented soon. bors-ng is really well maintained

It does prioritization now. Shout-out to @khodzha for implementing it, BTW!

[ishitatsuyuki]

@alexcrichton I think it’s a good time to migrate to bors-ng. Are you interested in rolling it out on all nursery repositories, or even cargo?

[notriddle]

It’s already being adopted at crates.io. Be patient; there’s still a few missing features before the bigger rust-lang repos can use it.

[gnzlbg]

any progress ?

[ishitatsuyuki]

any progress ?

Why are you hurrying?

[gnzlbg]

Last comment was in september last year, so I’d assume there have been some progress on this front, and maybe those working on it could give a short update like “we have done this and that, but this and those things are still missing”. Maybe there is a github issue tracking this that I’ve missed.

[notriddle]

Welp, I know one of the big blockers was bors retry, which bors-ng just added .

[asomers]

Another advantage of bors-ng is that it works with Cirrus-CI. Homu does not. https://github.com/rust-lang/libc/issues/1173#issuecomment-446002451 .

[pietroalbini]

Another advantage of bors-ng is that it works with Cirrus-CI. Homu does not. https://github.com/rust-lang/libc/issues/1173#issuecomment-446002451

Support for receiving checks has been added to Homu, btw.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.