Skip to content

bors should not try to merge a PR if the CI has failed #67

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
varkor opened this issue Sep 27, 2019 · 7 comments
Open

bors should not try to merge a PR if the CI has failed #67

varkor opened this issue Sep 27, 2019 · 7 comments

Comments

@varkor
Copy link
Member

varkor commented Sep 27, 2019

In the rare occasions we might want to merge even if CI has failed, we should explicitly command @bors to ignore the CI failure.

@Mark-Simulacrum
Copy link
Member

Why would this ever be the case? I'm quite confused -- is there some context here? Bors does check the CI status (otherwise, you know, there'd be no point...?)

@varkor
Copy link
Member Author

varkor commented Sep 27, 2019

Sorry, I thought someone indicated otherwise, and I must have misunderstood.

@varkor varkor closed this as completed Sep 27, 2019
@Mark-Simulacrum
Copy link
Member

Discussed briefly on Discord. Turns out @varkor presumably meant that if the PR CI fails, we should not then go and try to test on auto branch CI, since that's probably a waste of time.

@RalfJung
Copy link
Member

RalfJung commented Dec 3, 2019

Yeah, it would be great if bors either waited until PR CI passed before adding the PR to the queue, or else de-queued PRs (auto-bors r-) when PR CI fails.

@jyn514
Copy link
Member

jyn514 commented Apr 30, 2021

Maybe easier to implement - if bors could show on the queue that PR CI failed, it would at least let people know it wouldn't be included in rollups: rust-lang/rust#84716 (comment)

@jackh726
Copy link
Member

jackh726 commented Apr 30, 2021

Or better: if CI fails, then it automatically gets r-ed

Oh that was said

@camelid
Copy link
Member

camelid commented Apr 30, 2021

Another approach to this is r+ await (#120).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants