feat(stale): name the repo on every PR line in the Slack digest (BE-4574)

[mattmillerai]

ELI-5

The Stale PR bot posts a Slack digest listing the PRs it just marked stale or closed. Each line only said #3523 — no repo. That reads fine when one repo is posting, but the same bot runs (and will increasingly run) in several repos into the same channel, so #3523 is ambiguous the moment a line is quoted, forwarded, or read on its own. This makes every line say Comfy-Org/cloud#3523 instead.

What changed

fmt() — the one line-builder used for BOTH the "Marked stale" and "Closed as stale" lists — now interpolates $REPO (github.repository, already in the step's env:) into the Slack link label:

before  • <https://github.com/Comfy-Org/cloud/pull/3523|#3523> ci(frontend-rotation): ...
after   • <https://github.com/Comfy-Org/cloud/pull/3523|Comfy-Org/cloud#3523> ci(frontend-rotation): ...

The header (*Stale PR bot — ${REPO}*) is unchanged and still names the repo — the per-line name is additive, not a replacement. Comments + the README catalog entry are updated to match.

BE-2776 built this reusable and deliberately scoped out per-line naming ("keep the per-PR link lines as-is — they already resolve correctly"). This is the follow-up that adds it.

Why it's safe

• Format-only. No change to which PRs are staled/closed, to the actions/stale inputs, to the if: gating, or to the Slack POST/error handling.
• The existing slack_escape on the title is untouched, and $REPO itself needs no escaping — GitHub constrains github.repository to [A-Za-z0-9._-]+/[A-Za-z0-9._-]+, which contains none of & < >.
• The link target was already built from $REPO, so the label now simply matches the URL it points at.

Testing

• Ran the exact new jq expression against a fixture matching actions/stale's output shape (a normal PR, a PR with a hostile title containing <!channel> / & / a masked <url|label> link, and a PR with no title key) plus the empty-string and [] inputs. Output:

  • <https://github.com/Comfy-Org/cloud/pull/3523|Comfy-Org/cloud#3523> ci(frontend-rotation): add optional minor bump via workflow_dispatch
  • <https://github.com/Comfy-Org/cloud/pull/158|Comfy-Org/cloud#158> evil &lt;!channel&gt; &amp; &lt;https://x|click&gt;
  • <https://github.com/Comfy-Org/cloud/pull/42|Comfy-Org/cloud#42>
  

  Escaping still holds; missing title still degrades to empty; empty/[] inputs still produce no lines.
• actionlint .github/workflows/stale.yml — clean.
• zizmor v1.22.0 --no-online-audits — no findings.
• Not verified live: this reusable currently has no callers (both cloud and comfy-infra still run their own standalone copies), so no scheduled run exercises it yet. The companion PR below makes cloud the first caller.

Companion / merge order

Comfy-Org/cloud#5588 migrates cloud's standalone stale.yml to a thin caller of this reusable. Merge this PR first, then bump the SHA pin in that PR to the resulting main commit before merging it — otherwise cloud calls the pre-change reusable and the digest gets the repo name in the header only.

Follow-ups (not in this PR)

• comfy-infra/.github/workflows/stale.yml is also still a standalone copy — same migration applies there; the ticket calls it out as a follow-up.
• There is no bump-stale-callers.yml alongside the existing bump-*-callers.yml workflows, so caller SHA pins for this reusable have to be bumped by hand. Worth adding once it has real callers.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 29 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 098865b5-693e-41bf-841a-60939a32c2eb

📥 Commits

Reviewing files that changed from the base of the PR and between 29a81ca and 81d2894.

📒 Files selected for processing (2)

• .github/workflows/stale.yml
• README.md

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch matt/be-4574-stale-per-line-repo

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch matt/be-4574-stale-per-line-repo

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🔍 Cursor Review — Consolidated panel

Triggered by @mattmillerai.

✅ No high-signal findings.

Panel: 8/8 reviewers contributed findings.