It happens from time to time that tide merges a PR when re-triggering a GitHub action. This results in the following contextual situation:
We can see that e2e-fedora has not passed but also not yet started. Example PR:
Tide still merged the PR, I assume because of a race like outlined in:
|
// The list of all open PRs may not contain a PR if it was merged before we |
|
// listed all open PRs. To prevent a new PR that starts in the pool and |
|
// immediately merges from missing a tide status context we need to ensure that |
|
// every PR in the pool is processed even if it doesn't appear in all. |
|
// |
|
// Note: We could still fail to update a status context if the statusController |
|
// falls behind the main Tide sync loop by multiple loops (if we are lapped). |
|
// This would be unlikely to occur, could only occur if the status update sync |
|
// period is longer than the main sync period, and would only result in a |
|
// missing tide status context on a successfully merged PR. |
|
for key, poolPR := range pool { |
|
if !processed.Has(key) { |
|
process(&poolPR) |
|
} |
|
} |
It happens from time to time that tide merges a PR when re-triggering a GitHub action. This results in the following contextual situation:
We can see that
e2e-fedorahas not passed but also not yet started. Example PR:Tide still merged the PR, I assume because of a race like outlined in:
prow/pkg/tide/status.go
Lines 478 to 492 in f9126b3