Support changing GitHub username

[rickybassom]

Describe the bug

As highlighted by @cassidyjames here when a GitHub user changes their username houston can't process the user's apps. I don't know the technical details of this problem, maybe @cassidyjames can expand on this here?

I would also appreciate if someone from the elementary team solved this problem for my account as soon as possible as my apps have been unavailable for close to 3 months now.

To Reproduce

Steps to reproduce the behaviour:

1. Publish an app
2. Change your GitHub username
3. Update your app
4. You can now no longer update your apps

Expected behaviour

Houston should continue working as normal after a GitHub user updates their username.

[matfantinel]

I have 2 apps in AppCenter (Reminduck and Moneta) and am considering changing my GitHub username. So I can be a lab rat if needed.

[cassidyjames]

So the root issue is that Houston itself uses the GitHub username to verify the RDNN of your app. We require strict RDNN to avoid conflicts and to always be able to verify where an app is coming from. That trickles down from authenticating to the dashboard itself to the package names of your app in the debian repository, to the app ID your app uses for things like AppData, its .desktop file, etc. Changing the RDNN is not supported throughout all of these technologies without lots of manual intervention, so we don't currently support it in AppCenter.

One possible route could be to carry a manual one-off remapping of usernames/RDNNs that we carry in Houston to patch over these differences—basically, if olduser changed their username to newuser, we could let newuser use com.github.olduser in their RDNN. The problem becomes that a new GitHub user could potentially pick up the olduser username and wreak havoc on things by publishing conflicting apps… so this is not perfect but would probably work for now.

[rickybassom]

Thank you for explaining the problem @cassidyjames.

I think that's a good solution for now since only a couple of users are facing this issue. I would be happy to try your solution by changing my app's RDNN to the old version. Then we could test if the mapping works. Should I create new releases now with the old RDNN to test it out?

Would it not be possible to create a completely new user by removing old user data then adding the user back?

[cassidyjames]

We discussed this on a call today. There is still some manual work on our end to resolve this, but one thing you'll need to do in your app is to update the provides in your AppStream to provide the old RDNN. Then we'll need to:

• Update AppCenter to be smarter about provides, especially around payments (Handle provides in AppStream data appcenter#1439)
• Manually generate a transitional package to get users to upgrade to the new package seamlessly
• Figure out how to avoid duplicate app listings, i.e. in the AppCenter native client (Handle provides in AppStream data appcenter#1439) and website Prevent duplicate apps when newer package uses provides appcenter-web#52

The plan is to more loudly discourage changing GitHub usernames in documentation while also documenting the manual process in case it does happen while we're still built on debian packages. In the future, we hope to revisit how RDNN works with Flatpak packages and the new developer dashboard, making this less manual from the start.

[cassidyjames]

It might be obvious, but I want to note that this is also an issue if an associated org changes its name, or if a repo moves GitHub accounts or orgs. In the later case, it feels like the right thing is to treat it as a new app, but I'm not sure.

[rickybassom]

@cassidyjames That sounds like a good plan. I've updated provides and made new releases for both of my apps to use the old RDNN so you can use my apps to test your solution:

• https://github.com/rickybassom/date-countdown
• https://github.com/rickybassom/gtk-gist-manager

[rickybassom]

Hi @cassidyjames, have there been any updates to this issue so I can get my apps back on the AppCenter?

[rickybassom]

Are there any plans to fix this?