Improve Github keyword matching

[gstokkink]

Github allows additional spacing and a single colon character between the Github keyword and the issue number.

[github-actions]

No linked issues found. Please add the corresponding issues in the pull request description.
Use GitHub automation to close the issue when a PR is merged

[gstokkink]

@simoneb @agubler Github allows a slightly different (more lenient) syntax for closing issues than your Github Action currently allows. This bring it more in sync.

So, it will also allow, for instance, Resolves: #1234 or Fixes #1234.

[Copilot]

Pull Request Overview

This PR updates issue-reference extraction to support an optional colon and flexible spacing after GitHub keywords.

• Broaden extractLocalIssues and extractExternalIssues regex patterns to allow a colon and extra whitespace before the issue number or URL
• Adjust mock data in tests to include cases with colons and varied spaces

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
src/util.js	Updated both extractLocalIssues and extractExternalIssues regexes
mocks/@actions/github.js	Modified mock PR bodies to include colon variants and extra whitespace

Comments suppressed due to low confidence (2)

src/util.js:137

• Same issue in the external-issues regex: (?:\s*:)? won’t match a colon directly after the keyword. Switch to (?::)? to cover both closes: and closes : cases.

/\b(close|closes|closed|fix|fixes|fixed|resolve|resolves|resolved)(?:\s*:)?\s+(https?:\/\/github\.com\/)*.../gim;

src/util.js:121

• Add unit tests covering cases with no-space colon (e.g., fixes:#123), colon with space (e.g., fixes: #123), and without a colon (e.g., fixes #123) to confirm the updated regex handles all variants.

function extractLocalIssues(body) {

[simoneb]

Can you please create new test cases instead of modifying existing ones?

[gstokkink]

@simoneb not sure why, that would involve a lot more effort. The current tests are fine, just the mocked data is slightly adjusted to also test the more lenient syntax, along with the existing syntax.

[simoneb]

@gstokkink I'm testing your modified regexp for local issues but I can't seem to make it match what you suggest should be matching, e.g. the double spaces. Is this scenario intended to be handled?

[gstokkink]

@simoneb interesting, that should match as well. I'd expect the \s+ to take care of that. Might be a case of greedy matching going wrong, in which case I need to change the regex slightly. I'll check tomorrow.

[simoneb]

@gstokkink having specific tests for the new format may help, because I'm confused as well. Reading the new regexp you wrote, it makes sense to me, but then the test I did doesn't work, so I hope that tests will clarify this. We should consider testing the regexp matching functions in isolation.

[gstokkink]

@simoneb ah, I see your mistake. You added the g flag, which makes the regex stateful. This is useful when using exec to progressively find matches in a string (as in the code), but won't work for your tests in the console. Try dropping the g flag (i.e., use im instead of gim) and it should work as expected.

[gstokkink]

@simoneb Thanks for merging! Can we get a new release as well? 😄

Edit: cheers!