-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
bors is/went haywire #7293
Comments
cc @graydon |
bors seems to have successfully killed buildbot, so I think it will stop now.... |
nevermind, it keeps force-pushing single pull requests over and over and starting endless builds cancelling the builds just makes it move onto the next pull request and repeat the same process of pushing them over and over :( |
At 15 builds now. |
My apologies. I tried to teach bors to cope with transient github API failures a little better yesterday. Clearly the cure was worse than the disease. I've reverted that change. Unfortunately because github is so flaky on the API side, the larger the pull request queue gets, the more likely github will return a failure at some point during a single bors run. At 39 entries in the queue, it happens every couple of runs (i.e. we're only getting a "complete" bors-step run every 6 or 9 minutes). I will try a different failure-coping strategy on monday. Meanwhile I've cancelled all builds and reverted the previous attempt in bors' logic. I'll let it run "normally" over the weekend. Sorry. |
Nothing about the retry logic has changed. I expect the slow response is just it losing runs due to github api errors. I'd appreciate it if you just let it drain the queue some, rather than interfering with the tests. Manually combining multiple pull requests will also help. |
Ah, nevermind my last comment. Seems to be fine now. |
I believe the haywire-ness is solved for now. Closing this. Open a new one if it behaves badly. |
@thestinger and I were trying to get #7289 merged, but it bounced the first time so he rebased, and I re-reviewed; but bors didn't pick it up, so @thestinger closed the PR and reopened it as #7292 (with the same commit). This meant that bors picked up #7289 (the original and closed PR). Closing #7292 and reopening #7289 removed #7289 from the status page and added #7292, so @thestinger closed both, and moved the commit to #7274. Bors then merrily merged #7289 (it was closed) before the previous patch (#7210) had finished running, and then remerged #7210 so there were 3 separate auto builds happening concurrently (two of the same pull request).
(It seems there are several bors processes running, e.g. the multiple sets of comments on #7274.)
It got worse... 3 lots of the one pull request (#7274):
The text was updated successfully, but these errors were encountered: