ci: support cross-repo and private issue references in link-issue workflow

[mbiuki]

Summary

• Extends issue_comp_link-issue-to-pr.yml to accept owner/repo#NUMBER and full GitHub URL formats alongside the existing same-repo #NUMBER detection
• Cross-repo references (e.g. Closes dotCMS/private-issues#642) now pass the check without requiring a public placeholder issue
• Team-label validation passes gracefully when the linked issue is in a private/inaccessible repo
• Same-repo-only side effects (PR-list comment on the issue, bare #N appended to PR body) are skipped for cross-repo references to avoid creating broken links
• Failure comment updated to document all three supported reference formats

Test plan

• PR with Fixes dotCMS/private-issues#N passes link-issue check
• PR with Closes https://github.com/dotCMS/private-issues/issues/N passes link-issue check
• PR with Fixes #N (same-repo) continues to pass and still gets the PR-list comment on the linked issue
• PR with no issue reference still fails with the updated failure comment showing all three options

References

Closes #36457

🤖 Generated with Claude Code

[claude]

Claude finished @mbiuki's task in 4m 35s —— View job

---

Code Review: cross-repo issue reference support

• Read PR diff
• Analyze detection logic & downstream conditions
• Post review

Reviewed .github/workflows/issue_comp_link-issue-to-pr.yml. The detection logic is well-structured and the two AI-review fixes landed correctly:

• Priority ordering — same-repo #N (line 91-92) is extracted before any cross-repo pattern, so Fixes #123 can't be shadowed by a stray owner/repo#N. ✅
• Self-reference routing — both the owner/repo#N branch (line 119) and the URL branch (line 140) compare case-insensitively against $GITHUB_REPOSITORY and re-route to same-repo so side effects still run. ✅
• The same-repo regex is byte-identical to the pre-PR version and all cross-repo branches are purely additive, so regression risk on the existing Fixes #N path is minimal. The downstream side-effect steps (comment on issue, #N body-patch) are correctly gated with is_cross_repo != 'true' (lines 362, 378, 455, 462, 475).

I confirmed the var=$(… | grep …) no-match pattern (e.g. line 299, 324) does not abort under GitHub's default set -eo pipefail — the pre-existing team-label friendly-error path relies on exactly this and works, so the new grep-assignments inherit the same safe behavior.

New Issues

• 🟡 Medium: .github/workflows/issue_comp_link-issue-to-pr.yml:298-307 — the cross-repo label check swallows every gh issue view failure as "implicit approval". A typo'd or nonexistent reference like Fixes dotCMS/typo-repo#999 fails the fetch and passes the check with zero validation, indistinguishable from a genuine private-repo 403. Since the whole point of this workflow is to guarantee a real linked issue, consider distinguishing 404/not-found (fail) from 403/forbidden (pass). At minimum the current behavior means the "linked issue exists" guarantee is best-effort for cross-repo refs — acceptable if intentional, but worth calling out. Fix this →

• 🟡 Medium: .github/workflows/issue_comp_link-issue-to-pr.yml:105-106 — the cross-repo pattern [a-zA-Z0-9_.-]+/[a-zA-Z0-9_.-]+#[0-9]+ can false-positive on non-repo text after a keyword, e.g. Fixes utils/helper#2 or Closes path/to#5. Because same-repo #N is checked first, this only bites when the body has no plain #N but does contain a word/word#num token — a real issue would then be misread as cross-repo and its same-repo side effects skipped. Assumption: such tokens are rare in PR bodies. What to verify: whether any existing PR templates or common phrasings produce word/word#digits. Low likelihood; flagging for awareness, not blocking.

Both items are non-blocking. No 🔴/🟠 issues — the change is safe to merge from a correctness standpoint.
• ci/link-issue-cross-repo-support

[mbiuki]

Hey @nollymar — since you introduced and hardened this workflow (dc5ec7d), tagging you for review on this one. The fix adds support for cross-repo issue references (owner/repo#N and full GitHub URLs) so PRs tracking work in private repos don't fail the check. Would love your eyes on the detection logic and the downstream step conditions.

[mbiuki]

@nollymar The two issues flagged in the AI review are now fixed (commit 642ca0c). When you get a chance, could you take another look? Summary of what changed:

1. Priority — same-repo #N is now checked first, so Fixes #123 can't be shadowed by a stray owner/repo#N elsewhere in the body.
2. Self-reference — after extracting the owner/repo from a cross-repo match, we now compare it case-insensitively to $GITHUB_REPOSITORY; if they match it routes as same-repo so all side effects still run.

Thanks!

[mbiuki]

@nollymar Gentle ping — this one is blocking PR #36344 from merging. Both fixes from the AI review are in (commit 642ca0c). Would appreciate a review when you have a moment. Thanks!

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request