search

github / gh-gei

Migration CLI for GitHub to GitHub migrations
MIT License
328 stars 89 forks source link

Add `unlock-repo` command #593

Open dylan-smith opened 2 years ago

dylan-smith commented 2 years ago

Since we now have (or soon) the ability to lock the source repo when doing GH->GH migrations, it would be convenient to have an unlock-repo command in gh gei. Today customers would have to use the unlock API if they wanted to unlock a repo that GEI had locked for them (https://docs.github.com/en/rest/migrations/orgs#unlock-an-organization-repository)

tambling commented 2 years ago

Because the unlock repo API requires the (export) migration ID, I see two possible options:

  1. Add gh gei unlock-repo and require the user to provide the right migration ID, or
  2. Add a flag to gh gei migrate-repo that unlocks the source repo on success.

I prefer the latter, but I'm curious to hear others' thoughts.

EDIT: Both is also an option.

tambling commented 2 years ago

Second update: this is actually much harder than it should be:

Off the top of my head, I can think of three ways around this, none terribly pleasant:

All of the three require either a moderately large change on Octoshift, or an Octoshift change and a monolith change; any way we go, this isn't the quick win we thought it was.

dylan-smith commented 2 years ago

I don't like any of these. As a customer I just want to give a repo name and have it unlock. What if I did the migration days ago and no longer have the migration ID, but the repo is still locked? What would a customer do today?

dylan-smith commented 2 years ago

if we have the repo name can we lookup the migration id?

tambling commented 2 years ago

Short answer: yes, you can get all migrations, and the response has the repos for each migration; we could then iterate over the migrations and filter that way.

Question behind the question: why are customers wanting to unlock repos in the first place? Are they locking on dry runs, or are they intending to continue using a migrated repo? I guess the most likely answer is just spot-checking data fidelity, which I suppose I understand.

dylan-smith commented 2 years ago

We're going to put this item back on the backlog due to it being more work than anticipated. Will revisit in the future.

andyfeller commented 1 year ago

@dylan-smith : for what its worth, having the gh gei unlock-repo MIGRATION_ID would suffice for the short term as I myself ran into this issue during a services engagement but the customer was unaware how to unlock it themselves 👍

timrogers commented 1 year ago

@dylan-smith : for what its worth, having the gh gei unlock-repo MIGRATION_ID would suffice for the short term as I myself ran into this issue during a services engagement but the customer was unaware how to unlock it themselves 👍

Sadly a GEI migration ID won't work - it has to be a numeric migration ID, which we do output to the logs during a GHES-to-GHEC migration, but not a GHEC-to-GHEC migration.

timrogers commented 1 year ago

We do definitely need to look at this though! 🙏🏻

Mu-Reslife commented 1 year ago

Is there a way to get numeric GEI Id, all I have is the GEI migration id and I can't unlock repo with this one.

timrogers commented 1 year ago

@Mu-Reslife There isn't any way to do that at the moment. Unfortunately, if you need to unlock a repo, you would need to contact GitHub Support. Sorry for the pain!

vaishnav-canarys commented 1 year ago

@timrogers @dylan-smith We have run into this issue as well. There was some issue with the migration, now both the source and destination repos are locked. We are waiting for support team to respond. Is there any other way to unlock the repositories.

timrogers commented 1 year ago

@timrogers @dylan-smith We have run into this issue as well. There was some issue with the migration, now both the source and destination repos are locked. We are waiting for support team to respond. Is there any other way to unlock the repositories.

Can you send the URL of the support ticket to the email on my profile? I can take a look.

vaishnav-canarys commented 1 year ago

@timrogers there was a slight miscommunication.. client had locked the source repos using lock repo flag. The destination repos were fine. they still needed to unlock the source repos. Temporarily we are using a workaround to generate a new migration id for the required org and repos using the api.. we are using this migration id to unlock the repos. Thank you for the prompt response