CI: automatically approve a PR if has auto-approve label

[fee1-dead]

I have no idea if this would work. But given that a lot of people (including me) would like to have this feature, I took a stab.

The current design is placing a dedicated label on PRs such that, when CI has successfully ran, GitHub Actions will tell bors to r= the current assignee of the PR.

[rust-highfive]

r? @pietroalbini

(rust-highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

I would like to see some kind of discussion on why we're interested in this feature / what the goal is. In general, it seems like the wrong place to put it -- if we want bors to wait for PR CI to pass before respecting r+, then adjusting bors seems like a better plan (e.g., rust-lang/homu#67, rust-lang/homu#120).

As-is, I don't think this would work, since the user GitHub uses isn't trusted by bors. Further, it would mean that "write" permissions on this repository are enough to merge PRs into master, which is also not what we want (I think today this is more murky in any case, I'm not sure the extent to which branch protections etc are enough here, but we don't want that to look benign via bors testing things).

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

configure: rust.debug-assertions := True
configure: rust.overflow-checks := True
configure: llvm.assertions      := True
configure: dist.missing-tools   := True
configure: build.configure-args := ['--enable-sccache', '--disable-manage-submodu ...
configure: writing `config.toml` in current directory
configure: 
configure: run `python /checkout/x.py --help`
Attempting with retry: make prepare
---
   Compiling thiserror v1.0.30
   Compiling yaml-merge-keys v0.4.1
   Compiling expand-yaml-anchors v0.1.0 (/checkout/src/tools/expand-yaml-anchors)
    Finished release [optimized] target(s) in 4.76s
error: .github/workflows/ci.yml is not up to date; please run `x.py run src/tools/expand-yaml-anchors`.
caused by: src/ci/github-actions/ci.yml and .github/workflows/ci.yml are different

[fee1-dead]

I would like to see some kind of discussion on why we're interested in this feature / what the goal is.

Yes. That is what I wanted most when I opened this PR. I believe the problem is that when a commit is pushed or when a PR is opened, a reviewer sees that there are no problems and would like to approve the PR, but the CI is still pending. An example of an eager review is #100336 (comment) - where the PR is approved before CI ran and CI failed afterwards. On the other hand, not approving it adds more work for the reviewer as they would then need to go back to the PR again and approve if they see the green results. (sometimes there is more work if the reviewer forgot that they believed the PR was good, so they have to go back and review again)

In general, it seems like the wrong place to put it

Agreed. I only opened this PR because I am not familiar with homu's infrastructure.

Thank you for pointing me to rust-lang/homu#120! cc @camelid, could we redirect the discussion to there instead?

[Mark-Simulacrum]

I'll go ahead and close this PR, but feel free to open a thread on #t-infra if you'd like to discuss solutions further.

[camelid]

@fee1-dead I'd love for someone to pick that PR up again, but unfortunately I won't have time myself and I don't remember much of the context of the code. Let me know if you have questions about it though and I'll try to answer them.