Post comment on commit message referencing an issue

[webpro]

Still can't live without this package folks, thanks for maintaining it! ❤️

So I was looking for a solution to have a comment pushed to an issue (not a PR) that's mentioned in a commit message. Each push results in a pkg-pr-new publish anyway, so I thought why not try this use case too?

This works:

https://github.com/webpro-nl/knip/blob/dad24c59ae24378adcc0f0a5d386e99d94519e67/.github/workflows/integration.yml#L28-L52

Result: webpro-nl/knip#1382 (comment)

This seems to do the job just fine. Then it got me wondering if I missed something and there's a better/easier way? Would be cool if the comment would come from the pkg-pr-new bot instead. If that makes sense?

[btea]

I've already created the relevant pull requests, which I think are sufficient for most cases. However, there are some special cases that I'm unsure how to handle.

1. When multiple pull requests address the same issue, how should comments on the issue side be handled?
2. When a pull request fixes multiple issues, should I comment on all of them?

cc @webpro @AmirSa12

[AmirSa12]

hey! this is an amazing feature to add. thanks @btea for working on that!

When multiple pull requests address the same issue, how should comments on the issue side be handled?

I think its reasonable to have one comment that reference multiple pr(s)... so for example if one PR reference issue X, in the comment we include that. if another PR, references X again, we update that comment to include that PR too! this way its updatable, non-spammy.

When a pull request fixes multiple issues, should I comment on all of them?

yes, commenting on all referenced issues is reasonable but only if explicitly referenced e.g. ( Fixes # X / Closes # X / Resolves # X)
what do you think @btea ?

@webpro I'd love to know your opinion as well

[btea]

yes, commenting on all referenced issues is reasonable but only if explicitly referenced e.g. ( Fixes # X / Closes # X / Resolves # X) what do you think @btea ?

Yeah, that looks great. These keywords are usually used to link issues. To match more scenarios, (es) could perhaps be made optional; I've encountered many PRs that don't include it when linking issues.

[Aslemammad]

i think there should be an api in github to receive all the linked issues in a pr.

[webpro]

My intention is to have a prerelease published by mentioning an issue in a more generic sense, not necessarily when closing one. That way, stakeholders can try the published version and test and confirm it works or not, etcetera, before closing the issue.

If publishing a prerelease on merely mentioning an issue is a bit much or unexpected, perhaps we could opt-in or opt-out of the default behavior with a setting, or by using a prefix in the commit message itself (e.g. either "commit message (pkg #1)" or "commit message (skip-pkg #1)").

[btea]

If publishing a prerelease on merely mentioning an issue is a bit much or unexpected, perhaps we could opt-in or opt-out of the default behavior with a setting, or by using a prefix in the commit message itself (e.g. either "commit message (pkg #1)" or "commit message (skip-pkg #1)").

Do you mean to actively include the associated issue number in the commit message? Does this need to be included in every commit of the PR? If not, do I need to iterate through the commit history of the PR to extract the issue number?

[btea]

Perhaps we can match issue numbers in the comments of a pull request based on the special prefixes mentioned above (but not automatically match "close" or "fix").

[webpro]

The workflow I had in mind is this:

• Somebody opens an issue 123
• Maintainer pushes a commit (in any branch, not necessarily a PR) mentioning issue 123
• A prerelease is published and a comment referencing it is added to issue 123

[btea]

Oh, that makes sense. Not all changes will be submitted as a pull request.