-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Bors: 422 Update is not a fast forward #43535
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Labels
A-CI
Area: Our Github Actions CI
A-spurious
Area: Spurious failures in builds (spuriously == for no apparent reason)
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
T-infra
Relevant to the infrastructure team, which will review and decide on the PR/issue.
Comments
cc servo/homu#24. Could bors (homu) automatically wait for 5 seconds, and then push again in case of 422? |
This was referenced Aug 7, 2017
If we can track down where in the code this come from, I will try and add a retry. |
Is the error that is being cout there thrown by github_set_ref? If so can we add a retry in github_set_ref, as it already has 422 special cases? |
bors-servo
pushed a commit
to servo/homu
that referenced
this issue
Oct 2, 2017
retry if 422 Update is not a fast forward As @kennytm suggested in rust-lang/rust#43535 This is a quick fix to try and suppress the [intermittent 422 errors.](#24) <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/homu/134) <!-- Reviewable:end -->
Move to close? |
Triage: Still seems to be an issue according to rust-lang/homu#75 |
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Labels
A-CI
Area: Our Github Actions CI
A-spurious
Area: Spurious failures in builds (spuriously == for no apparent reason)
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
T-infra
Relevant to the infrastructure team, which will review and decide on the PR/issue.
Periodically we'll see bors not manage to push the built PR into master for some reason.
This is possibly because of submodules not being synchronized? Wild stab in the dark.
The text was updated successfully, but these errors were encountered: