Command for linking a PR to an issue

[hbelmiro]

It would be nice to have a command for linking a PR to an issue. Something like /issue 42.

[Prucek]

Such behavior is working, when you mention the issue in the description of the PR with "fixes" or "resolves" with the PR link. E.g.: https://github.com/kubernetes-sigs/prow/pull/116

[hbelmiro]

Such behavior is working, when you mention the issue in the description of the PR with "fixes" or "resolves" with the PR link. E.g.: #116

@Prucek I know that. The problem is when contributors who don't know that send PRs without linking the issue. In these cases, we need to ask them to update the description. We could just drop a comment linking the issue instead.

E.g.: https://github.com/kubeflow/pipelines/pull/11512#issuecomment-2592783887

[petr-muller]

/kind feature

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[hbelmiro]

/remove-lifecycle stale

[krzyzacy]

/good-first-issue

[k8s-ci-robot]

@krzyzacy: This request has been marked as suitable for new contributors.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed by commenting with the /remove-good-first-issue command.

In response to this:

/good-first-issue

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[Amulyam24]

/assign

[Amulyam24]

Hi @hbelmiro, is the scope of this issue to create a new plugin under https://github.com/kubernetes-sigs/prow/tree/main/pkg/plugins or make use of a relevant existing plugin by adding a command to it?

[petr-muller]

I'd prefer to have a new plugin called issues or issue-management. I don't think we need a new plugin for just this new command, and I do not think we have an existing good one where this would fit. There seem to be at least one other request (#364) that would fit into a more generic issues plugin, and I can imagine eventually folding transfer-issue functionality there too.

[Amulyam24]

I'd prefer to have a new plugin called issues or issue-management. I don't think we need a new plugin for just this new command, and I do not think we have an existing good one where this would fit. There seem to be at least one other request (#364) that would fit into a more generic issues plugin, and I can imagine eventually folding transfer-issue functionality there too.

Thank you @petr-muller! I'll get started with a new plugin - issues, beginning with the linking feature. The WIP code shared in #364 will serve as a helpful reference.

[Amulyam24]

Hey @petr-muller, one question regarding linking PR to an issue functionality - should anyone be able to do it or should permissions for it be restricted to owners of project/repo or members of organisation?

[dims]

@Amulyam24 use the same pattern as used in /transfer

[Amulyam24]

Hey @petr-muller, I spent time in get to know the plugin flow and APIs to be used.

• After researching, I could see that linking a PR to an issue doesn't have a separate API. The operation on UI seems like a front end change.

• One approach we can follow is updating/appending the body of the PR using one of the supported keywords for linking and executing already existingupdatePullRequest REST API.

  PR body to be updated with Fixes: #issue-number

• Example commands to be commented on a PR would look like below supporting different scenarios:

/issue-link <issue-number>
/issue-link <issue-number> <issue-number> // for linking multiple issues in a repo
/isuue-link <issue-number> <repo-name/issue> // for linking to an issue in a different repo

/issue-unlink <issue-number>

Note: updatePullRequest is also supported via GraphQL where the PullRequest object has a filed closingIssuesReferences.

Does this make sense? Let me know your thoughts!

[Amulyam24]

Hi @petr-muller, would like to hear your suggestions/thoughts on the above, PTAL, Thanks!

[petr-muller]

Thanks for summarizing your findings, the results are unfortunate (it seems the amount of useful GH operations not exposed through an API for us to use them is growing over time?). I have looked at GH API docs and I found the same thing you did (=no api for this purpose). The GraphQL updatePullRequest mutation takes a limited subset of PR properties as an input, not including the closingIssuesReferences field you mentioned. I looked at what the UI does when the linking functionality is used, and found it actually makes a POST requests like

issues/closing_references?source_id=2876346254&source_type=PULL_REQUEST`

So GH has some kind of internal API, it just does not allow us to use it :D

So it really seems using keywords is the only option available, but I am somewhat careful because PR description is unstructured text and trying to automatically mess with it sounds brittle, especially the interaction with existing keywords which may be entered or altered by humans, and unexpected non-interaction with keywords in commits and manually UI-linked issues.

But I am not opposed to trying. I would suggest to start really simple: select a single form of the keyword, and expect it to be on a separated line, with no other content than a comma-separated list of items that are clearly an issue reference. Link operation searches for this line and adds the item to the list if not present. Adds the line if its missing. Unlink also searches, removes the desired item from the list and removes the full line if the last item was removed. Something like that. Ignore the potential interactions with other keywords entirely.

[Amulyam24]

But I am not opposed to trying. I would suggest to start really simple: select a single form of the keyword, and expect it to be on a separated line, with no other content than a comma-separated list of items that are clearly an issue reference. Link operation searches for this line and adds the item to the list if not present. Adds the line if its missing. Unlink also searches, removes the desired item from the list and removes the full line if the last item was removed. Something like that. Ignore the potential interactions with other keywords entirely.

I agree, added code on the same lines with using a single keyword Fixes. Needs more modification for handling scenarios when line exists and then shall proceed with testing, Thank you!

[VannTen]

But I am not opposed to trying. I would suggest to start really simple: select a single form of the keyword, and expect it to be on a separated line, with no other content than a comma-separated list of items that are clearly an issue reference. Link operation searches for this line and adds the item to the list if not present. Adds the line if its missing. Unlink also searches, removes the desired item from the list and removes the full line if the last item was removed. Something like that. Ignore the potential interactions with other keywords entirely.

Aren't multiples occurrences of Fixes in the PR description supported ? I'd expect it would be simpler and less error-prone to add whole lines for each "link" prow would manage

Fixes #1 // managed by prow, please don't edit
Fixes #2 // managed by prow, please don't edit

It makes it impossible to unlink issues if the description already contains manual keywords, but that's probably not as frequent as linking.

[Amulyam24]

Aren't multiples occurrences of Fixes in the PR description supported ? I'd expect it would be simpler and less error-prone to add whole lines for each "link" prow would manage

Fixes #1 // managed by prow, please don't edit
Fixes #2 // managed by prow, please don't edit

It makes it impossible to unlink issues if the description already contains manual keywords, but that's probably not as frequent as linking.

Hi @VannTen! Yes, multiple Fixes lines work and this should be a more straightforward way.

I don't mind trying this out. Thoughts @petr-muller?

[Amulyam24]

Hi, I was able to get the plugin working with a single fixes line and tested different scenarios successfully.

IMO, Single fixes line works seamlessly, will enhance the code a bit and raise a PR tomorrow or by early next week!