Missing webhook event for repo migrations
bfrancom opened this issue · comments
Description
When a repository is migrated to a new (destination) org, there doesn't seem to be a corresponding GitHub webhook event generated in the destination org.
Would it be possible to have a repository.migrated event? Or even generate a repository.created event, please?
Thanks,
-Ben
@bfrancom Thanks for reaching out! 👋🏻 We can definitely consider this feedback. Would you be able to tell me a bit more about how you'd like to use that event?
@timrogers , thanks for the follow up!
Currently I have a lambda that listens for any repo.created or repo.transferred event action. The Lambda then auto-assigns those repos to several teams with varying levels of rights to alleviate the burden of manually assigning them.
I'm starting a large migration of 100's of repos from an old org to a new org that is using the EMU licensing model. According to GitHub support, because of EMU limitations, I'm not able to add non EMU users to the EMU org (and vicey versey) to do a transfer. They recommended using GHEI.
I'm trying to automate as much as possible. So to facilitate the migration, I've set up a GitHub action (with workflow dispatch) that runs the gh-gei command to allow our teams to migrate their own repos autonomously.
I can still achieve what is needed via the API on the GitHub action, but I'd rather have the lambda take care of it all instead of maintaining similar code in different places. Ultimately I want any repo in the new org to be auto-assigned to several teams with different roles.
Thank you kindly!
-Ben Francom
I am also interested in this feature. The corporation I work for uses Github's safe settings app to manage branch protection rules for many of our repos.
However since migrated repos do not trigger the repo.created event, safe-settings is never applying the pre-configured branch protection rules to migrated repos.
Thank you both for taking the time to share your feedback ❤️ What you've said makes total sense, and we'll track this request internally.
I don't think we will be able to make progress on this in the next ~3 months, but we will keep this issue updated.