MDBF-1226: Make duplicate push builds yield to PR builds#979
Merged
RazvanLiviuVarzaru merged 2 commits intoJun 25, 2026
Merged
Conversation
RazvanLiviuVarzaru
force-pushed
the
fix/push-yields-to-pr-duplicate
branch
from
66e4348 to
2209044
Compare
RazvanLiviuVarzaru
changed the title
RazvanLiviuVarzaru
force-pushed
the
fix/push-yields-to-pr-duplicate
branch
from
2209044 to
97f6ca2
Compare
In a GitHub double-event, Buildbot can queue the push and pull_request tarball-docker requests together, but the push build may get a worker first and complete while the corresponding PR request is still waiting in the queue. By the time the PR build finally runs, it is too late to prevent the duplicate tarball work and any downstream triggers that already happened. The reverse can happen too: the PR build may finish before the push build gets a worker. To cover that without walking buildrequest history, the push side first checks incomplete same-builder requests, then falls back to only the 10 most recent completed same-builder requests. Flip the direction so the push side yields when it sees the matching PR request. That makes the first running duplicate decide whether it should continue, instead of depending on the PR side to arrive soon enough after the fact. The branch guard keeps this limited to disposable normal push branches: refs/* are ignored and branches covered by SAVED_PACKAGE_BRANCHES are not allowed to self-cancel.
RazvanLiviuVarzaru
force-pushed
the
fix/push-yields-to-pr-duplicate
branch
from
97f6ca2 to
d757205
Compare
fauust
approved these changes
Jun 23, 2026
RazvanLiviuVarzaru
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a fix for MDBF-1202 :: while working just fine for most of the time, there's a corner case where the PR build request sits in the queue for the whole duration of the push event build so it can no longer cancel its sibling.
In a GitHub double-event, Buildbot can queue the push and pull_request tarball-docker requests together, but the push build may get a worker first and complete while the corresponding PR request is still waiting in the queue. By the time the PR build finally runs, it is too late to prevent the duplicate tarball work and any downstream triggers that already happened.
The reverse can happen too: the PR build may finish before the push build gets a worker. To cover that without walking buildrequest history, the push side first checks incomplete same-builder requests, then falls back to only the 10 most recent completed same-builder requests.
Flip the direction so the push side yields when it sees the matching PR request. That makes the first running duplicate decide whether it should continue, instead of depending on the PR side to arrive soon enough after the fact.
The branch guard keeps this limited to disposable normal push branches: refs/* are ignored and branches covered by SAVED_PACKAGE_BRANCHES are not allowed to self-cancel.