hubcio opened a new pull request, #3283:
URL: https://github.com/apache/iggy/pull/3283
The stale workflow marked PRs stale but never closed them. The
bot's own labeling bumps `updated_at`, and the default
`remove-stale-when-updated: true` then removed the label on the
next cron run. Seven days later, the same PR was marked stale
again - cycling indefinitely (e.g. PR #3037 marked 4x in April).
Set `remove-stale-when-updated: false` so the bot keeps its own
label. `days-before-pr-close` is measured from label-add date,
so closure still fires on day +7.
Rename the bot's label from `stale` to `S-stale` to match the
S-waiting-on-review / S-waiting-on-author triage family.
Add companion workflows that drop the S-stale label on
contributor activity:
- stale-prs-unmark.yml: pull_request_target on synchronize /
reopened / ready_for_review. Uses `gh pr edit --remove-label`
(GraphQL, idempotent) so a parallel run or manual unlabel
between event delivery and the step run does not 404 red.
Adds `concurrency: cancel-in-progress: true` keyed on PR
number so rapid pushes do not fan out N runners, and
`timeout-minutes: 2` to match the pr-triage workflow
convention.
- stale-prs-unmark-on-activity.yml: workflow_run handoff from
pr-triage-collect.yml. issue_comment and pull_request_review
deliver a read-only GITHUB_TOKEN on cross-fork PRs, so the
label DELETE cannot run on the comment event itself. The
workflow_run leg runs against base ref with a write token,
downloads the event payload artifact, and removes the label
via the same idempotent path.
Also escape `@core` with backticks in the stale message to
avoid pinging a random GitHub user named "core".
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
