ash-nazg should handle repository name changes

[plehegar]

https://labs.w3.org/hatchery/repo-manager/pr/id/w3c/webpayments-core-messages/5

doesn't do anything when one tries to mark this PR as non-substantive. Note that the PR author doesn't appear as contributor in ash-nazg.

[plehegar]

This PR is at w3c/webpayments-http-messages#5

[dontcallmedom]

So the problem arises because the repository was moved (i.e. had its name changed), and ash-nazg doesn't handle this gracefully at the moment. Renaming the issue accordingly.

[dontcallmedom]

there doesn't seem to be an event in the GH API when a repo is moved at the moment, although it seems to be on the "wishlist".

A possible fallback solution in the meantime would be:

• to add a UI to a repo to reflect its new name (possibly new owner as well)
• to notify repo contacts when an event is received for a repo whose name doesn't match what we expect (not sure it can be done though)

[dontcallmedom]

Among other things that would need to be handled when a repo is transfered is ensuring the existing tracked open pull requests be re-associated to the new owner, associated with the right groups, and be re-validated accordingly.

[plehegar]

looking at the GH API feedback, it looks like the redirect will now happen properly but still no event. We could revalidate the repositories known to ash-nazg and detect the renaming at least.

[deniak]

Each GH repository actually have an ID which we can rely on and will work after a rename but this could require a bit of work as ash-nazg currently heavily relies on the 'owner/shortname' of the repo

[deniak]

As far as I can see, the best option would be to update ash-nazg to listen to the rename event and update the name of the repository or add a new repo in the repository manager but it will require an update of the webhook to listen to repository event.
Another option could be to create a cronjob that will fetch all the repositories in the repo manager and see if there was a rename. It's not ideal as we will miss the PRs submitted between the rename and the run of the cronjob.

[dontcallmedom]

the rename event didn't exist back when this issue was raised - I agree that it sounds like the right approach.

[plehegar]

I'm ok ok either, whatever is the easiest to implement. I'm not worried about missing PR within 24 hours or less of a move.