Skip to content

fix(ci): recognize closing keywords for non-default-base PRs - #51971

Open
Veld101 wants to merge 1 commit into
anomalyco:devfrom
Veld101:ci-pr-standards-fallback
Open

fix(ci): recognize closing keywords for non-default-base PRs#51971
Veld101 wants to merge 1 commit into
anomalyco:devfrom
Veld101:ci-pr-standards-fallback

Conversation

@Veld101

@Veld101 Veld101 commented Sep 29, 2026 •
edited
Loading

Copy link
Copy Markdown

Issue for this PR

Fixes #51970

Type of change

  • Bug fix
  • New feature
  • Refactor / code improvement
  • Documentation

What does this PR do?

pr-standards labels every PR that targets a non-default base with needs:issue, even when the description contains a valid Closes #123 / Fixes #123.

It reads closingIssuesReferences, which GitHub only populates for PRs targeting the default branch, so a v2-targeted PR always reads 0. The v2 copy of pr-standards.yml already falls back to matching closing keywords in the description, but pull_request_target runs the workflow from the default branch, so the dev copy is the one that executes - and it has no fallback.

This ports that fallback from v2 to dev, so the running workflow stops flagging non-default-base PRs that do reference an issue. The change is exactly the block already merged on v2.

Runtime evidence

Confirmed from the check-standards job log on #50184 (run 36527091671, pull_request_target): the script it actually ran has no hasBodyIssueRef at all - it goes straight from closingIssuesReferences.totalCount to if (linkedIssues === 0). That is the dev copy, so the v2 fallback is dead in practice rather than just in theory.

The asymmetry is visible on live PRs: v2-targeted #51890, #51910, #51935 and #51986 each contain a plain Closes #N, each read closingIssuesReferences.totalCount === 0, and each carry needs:issue; dev-targeted #51989, #51979 and #51911 each read 1. Re-running the check by editing the body does not clear the label once applied (#50184 edited at 05:38Z: the job succeeded and needs:compliance was dropped in the same pass, but needs:issue stayed).

How did you verify your code works?

  • git diff of the added block matches the v2 version character-for-character (git diff upstream/dev upstream/v2 -- .github/workflows/pr-standards.yml).
  • The behaviour is observable only in CI on the next workflow run; there is no local test surface for actions/github-script. The condition is: with linkedIssues === 0, accept /(closes|fixes|resolves)\s+#\d+/i (or any #\d+) inside the ### Issue for this PR section of the body.

Screenshots / recordings

Not applicable; no UI change.

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR

@Veld101 Veld101 mentioned this pull request Sep 29, 2026
Open
3 of 6 tasks
@github-actions

github-actions Bot commented Sep 29, 2026

Copy link
Copy Markdown
Contributor

The following comment was made by an LLM, it may be inaccurate:

@feiiiiii5

feiiiiii5 commented Sep 29, 2026

Copy link
Copy Markdown

Independent confirmation, and the runtime artifact you said was not available locally.

A check-standards job from earlier today on #50184 — run 36527091671, pull_request_target — echoes the script it ran, and that copy has no hasBodyIssueRef at all: it goes straight from closingIssuesReferences.totalCount to if (linkedIssues === 0). That is dev's copy. So the v2 block is confirmed to be dead in practice, not just theoretically.

Four other PRs opened in the last two days are in the same state, each with a plain Closes #N line and each carrying needs:issue: #51890, #51910, #51935, #51986. closingIssuesReferences.totalCount reads 0 on all four. Against that, dev-targeted PRs do register — #51989, #51979 and #51911 each read 1 — which is the asymmetry your description predicts.

One more detail that may be worth putting in the description: re-running the check does not clear the label once it is applied. Editing #50184's body at 05:38Z today re-triggered check-standards; it ran, the job succeeded, check-compliance dropped needs:compliance in the same pass, and needs:issue stayed. For the five open v2 PRs affected on my side, the label is currently permanent until this lands.

@Veld101

Veld101 commented Sep 29, 2026

Copy link
Copy Markdown
Author

Thanks for the independent confirmation - the check-standards job log on #50184 is exactly the runtime artifact the description could not produce locally, and the totalCount asymmetry (#51890 / #51910 / #51935 / #51986 at 0 versus #51989 / #51979 / #51911 at 1) is decisive. I've folded your evidence into the description.

One precision: the v2 fallback is not dead code, it is just not the copy that runs. pull_request_target executes the workflow from the default branch (dev), which is why this PR ports the block there.

For the already-labelled PRs: once this lands on dev, editing the body of a v2 PR re-triggers check-standards, which will now find the closing keyword and drop needs:issue. Until then the label really is permanent, as you observed.

@Veld101 Veld101 mentioned this pull request Sep 29, 2026
Open
1 task done
@feiiiiii5 feiiiiii5 mentioned this pull request Oct 1, 2026
Open
3 of 6 tasks

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

pr-standards: needs:issue is applied to every v2-targeted PR despite a valid closing reference

2 participants

@Veld101 @feiiiiii5