comment on issues too

[zeke]

Comments are currently created on Pull Requests that land in a release, but we should also be able to track down the source issues that are resolved by a release too.

cc @rsarky

[pvdlg]

For info we are parsing the body of commits and PR (found with GitHub search for the commits part of the release) to find issues fixed by those PR and commits in semantic-release/github.

I couldn't find a solution that would parse properly the GitHub closing keywords. All the solution I found were "too naive" and missed some edge cases (ignoring references in back tick, fenced block or <code> blocks, missing weird variation with spaces, comma that GitHub recognize etc...). So I created issue-parser.

It's mostly developed after lots and lots of empirical tests. It works well so far and I think most cases should be covered, but that would be great if we had a way to get the actual regex/algorithm used by GitHub.

Do you think it's something GitHub would open source? Or is there any plan for the GitHub API to add the issues closed in the metadata of the PR/commit retrieved via API?

[zeke]

So I created issue-parser

👍

would be great if we had a way to get the actual regex/algorithm used by GitHub.

cc @megbird, who appears to have written the Closing issues using keywords doc. Meagan, do you know much about the implementation of this?

[rsarky]

would be great if we had a way to get the actual regex/algorithm used by GitHub.

I second this. I need a standardized way to parse a PR body for helpr. Currently it's very hacky and doesnt handle edge cases.

[pvdlg]

@rsarky you can check issue-parser in the meantime, I'll happily fix any edge cases you might find.

[rsarky]

@pvdlg Thanks 😄 I will check it out.

[zeke]

cc @cheshire137 who has done some work on this feature. Do you think extracting something reusable from GitHub's codebase is feasible?

[megbird]

👋 sorry I didn't see this until today. @zeke and I spoke about the documentation history and about how our move to nanoc a few years ago means we can't see who worked on this when the feature was initially shipped. I wish I was more helpful 😸

[rsarky]

@zeke Would you be open to a PR on this that uses @pvdlg 's issue-parser . I have been using it on helPR and it's been working like a charm.
Thanks again @pvdlg ✨

[zeke]

Would you be open to a PR on this that uses @pvdlg 's issue-parser

@rsarky yes definitely!

[rsarky]

So basically for each PR that was present in a release :

• Parse the PR body using issue-parser.
• If any issues are referenced add a comment saying they were fixed in so and so release.

I was wondering if this would be helpful though.
Issues automatically get closed whenever a PR referencing it gets merged. Is commenting on a closed issue gonna be useful?

[zeke]

Is commenting on a closed issue gonna be useful?

Yes, as the author and commenters will still be subscribed to it even though it's closed, and they may not be subscribed to updates on the resolving PR.

[rsarky]

@zeke That makes sense. I have my exams going on .
I will try to submit a PR by the weekend .