ci: Increase retry count on PR conflict check#25788
Conversation
|
For reference, the default is 5 retries with 2 minutes delay, so we are unfortunately already taking 10 minutes for this, and this bump would make it up to 20. Really it just means we need to go take a look at the blocked PRs. |
|
I'm fine with upping the limit, but its not actually obvious to me that that will have any effect... from looking at the logs, it looks like each retry restarts at the beginning and so it's not like doing it 5 more times will actually do anything. |
|
From the docs, the purpose of "retryAfter" is not to get more coverage, but rather to give GitHub time to calculate if the PR is mergable But after looking a bit more carefully at the logs with that in mind, that does actually seem to be the limiting factor here, not e.g. number of actions. So I think that is based on number of open PRs, not necessarily ones with label (it needs to check the ones that don't have a label to see if it newly needs it) But that doesn't explain why this is a new problem (well, I guess I don't know for sure that we would for sure notice super quickly) |
|
Let's if it improves the situation. |
3 participants
PR summary
We currently have enough open PRs with conflicts that the automated labels are no longer being added.
For example, #25787 had conflicts when #25607 was merged, but the logs show it was not ever considered as the action had only reached up to #22678. (Also, it was rebased before that could happen due to the action's retry delay, but the important thing is that the action didn't get to it yet.)
PR checklist