Command to move issue to a new repository

[sftim]

What would you like to be added:
GitHub lets you transfer an issue to another repository. I think this requires the GraphQL API.

Approvers with the appropriate access should be able to use a command to trigger moving an issue to a different repository.

Why is this needed:

Sometimes, people open great issues but in the wrong repository (eg documentation issues that ought to live in k/website in k/kubernetes, or issues about the built-in help for kubectl, which is mirrored onto the website, that should actually live in k/kubectl).

Rather than tell those people that the great issue they've filed is in the wrong place, we can add tools to help the person doing triage move it there.

At the moment you need write access on both repositories to do the transfer, so there are few people with the privileges to implement moves. Involving test-infra automation can add richer access controls and broaden the number of people able to take part in this aspect of triage.

[prasadkatti]

Another common use case would be k/website to k/minikube.

[sftim]

An example of an issue I'd nominate for move: kubernetes/website#22465

[spiffxp]

It looks like this isn't possible via the v3 api, would have to be done via the v4 graphql api, it's unclear to me whether different plugins could be written against different api's

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[sftim]

I'd like to see this implemented, but it wouldn't be used very often.

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[sftim]

Another example of an issue where Prow-facilitated moves could be useful: kubernetes/kubernetes#98368

/remove-lifecycle rotten

[spiffxp]

/sig contributor-experience
/assign @rikatz
mentioned a proposal to write such a plugin in #sig-contribex https://kubernetes.slack.com/archives/C1TU9EB9S/p1611252110007400

proposal: https://docs.google.com/document/d/1uqKI5QEAh2fnq7LRRz-2Mhf-jInIpuiAUnPow36jCVU/edit?usp=sharing

[rikatz]

Thanks Aaron

/assign @dougsland (Doug is going to work on this with me)

[rikatz]

/assign @dougsland

[rikatz]

OK, so I've started to look into the viability of this. Unfortunately Github does not support Issue move on their API. The Update endpoint only allows to update the title, body but not the owner or the repo.

I'm not sure if the GraphQL already supports this, should take a look, but AFAIK the Prow Github Client uses the rest/v3 API. Maybe this need to be an external plugin.

Doing some call debugging, I've seen that the process is basically:

• On an issue, call a POST with the "/transfer" endpoint (let's say github.com/myorg/myrepo/issues/1/transfer)
• On the request body, pass an authenticity_token (need to check if this can be an OAUTH, or what is this), the internal issue ID encoded in base64 (issue_id=MDU6SXNzdWU4MzYwMjczNzc= which means "05:Issue836027377" and the repository_id the same way

So here is the fun part: The meaning of "05:Issue836027377" is: the next field have 5 characters after ":" (Issue string) and then its internal issue ID (not the Number), so when moving, we should know the internal Issue ID, and the destination repo ID.

I'm not sure if we may have this sort of logic internally on some plugin, or if we should wait some API to rise (although the feature is from 2018, I guess).

I will continue to explore some options on this.

Oh, also one issue can be moved only between repos on the same org

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[eddiezane]

/remove-lifecycle rotten

Looks like the GraphQL API does allow this.

https://docs.github.com/en/graphql/reference/mutations#transferissue

[eddiezane]

Oh and here is how hub implements it!

https://github.com/github/hub/pull/2363/files

[eddiezane]

And how gh cli https://github.com/cli/cli/blob/09b09810dd812e3ede54b59ad9d6912b946ac6c5/pkg/cmd/issue/transfer/transfer.go.

Both are using GraphQL.

[eddiezane]

I started working on this in #23153

/assign

[rikatz]

Yey thanks Eddie. If I can help with something just ping me :) Em qui., 5 de ago. de 2021 às 22:03, Eddie Zaneski ***@***.***> escreveu:

…

I started working on this in #23153 <#23153> /assign — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#18117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABWZQBPFY4WSTJ2SAUX26O3T3MYF7ANCNFSM4OMPAYWQ> .