Reapply "workflows/labels: manage stale & merge conflict labels"#419654
Reapply "workflows/labels: manage stale & merge conflict labels"#419654wolfgangwalther merged 6 commits intoNixOS:masterfrom
Conversation
This reverts commit c366efa.
To set the stale label properly, we need to consider the right timeline events only - and their respective relevant timestamps.
When running in a pull_request context, the labels job is part of the currently running workflow - which will never have succeeded, yet. Apparently it could be failed already, so in this case we take *any* workflow run, no matter its state.
wolfgangwalther
force-pushed
the
ci-labels-stale-conflict
branch
from
045f1e9 to
2264f9b
Compare
nixpkgs-ci
bot
added
10.rebuild-darwin: 0
MattSturgeon
left a comment
MattSturgeon
left a comment
There was a problem hiding this comment.
I don't see any obvious issues.
Unrelated:
The size of the workflow step is starting to make me uncomfortable... maybe we can consider moving it into ci/ in another PR, although that'd mean introducing a sparse checkout into this job 😦
TBH, even moving the logic out of the workflow won't help much for testing or maintaining it... It is so tightly coupled to the reality of github's APIs and nixpkgs' scale. So probably not worth it.
I fully agree, but it would only be worth it, if this script could be run locally. I went that way once, but then wasn't satisfied with the surrounding infrastructure one would need (package.json, a way to install the deps into node_modules, wrapper for some of the actions/github-script stuff). So yeah.. I don't have a solution for this, so far. |
Explained very well by the code comment.
This should make sure that the timer is cleaned up, no matter what. This didn't seem to be the case before, where it would still be stuck sometimes, when throwing an error somewhere.
…l requests It's necessary to use a combination of different endpoints here, because the /search endpoint only allows fetching the first 1000 items and will fail with a higher page number (11+). On the flip side, the /pulls endpoint doesn't allow counting the total number of results, so we can't calculate the required page number with its response. Putting both together should work, though.
wolfgangwalther
force-pushed
the
ci-labels-stale-conflict
branch
from
2264f9b to
579bfd4
Compare
|
OK, let's try for the second time :) |
|
Successfully created backport PR for |
|
Successfully created backport PR for |
github-actions
bot
added
the
8.has: port to stable
|
Seems to work better, but the stale label is still not right in:
The stale label already works a lot better in many cases, also better than the stale bot's labeling, so far. But, I didn't find the pattern why the above are wrongly labeled, yet. |
2 participants
Reapplies #419481, which was reverted in #419574.
All issues found after merge are fixed here.
This passed basic testing my fork, but the issues we had were not detected this way before - so that's only a syntax check, not more. Most of those are impossible to recreate without scale.
Things done
Add a 👍 reaction to pull requests you find important.