Add `unlock-repo` command

[dylan-smith]

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]

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]

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

• The API requires the migration ID from the archive generation (as noted above)
• When we're migrating from GHES to GHEC, we can capture the export ID
• When we're migrating from GitHub.com to GHEC, the archive generation gets kicked off by Octoshift and the export ID isn't exposed anywhere.

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

• We expose the export ID in the Migration GraphQL object (then consume it in gh gei and feed it to the unlock endpoint)
• We add a flag to StartRepositoryMigration to unlock the source repo on success (similar to how we do lockRepo right now)
• We move GitHub.com archive generation to gh gei

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]

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]

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

[tambling]

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]

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]

@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]

@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]

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

[Mu-Reslife]

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]

@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]

@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]

@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]

@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