Dry Run

Dry Run

Open Copy into the sandbox, Resolve special cases, and Keep copies fresh from the Migration Plan journey. A dry run copies the plan's repositories into the sandbox organization — the organization the plan lives in, not a destination org — so you can see how the move goes before a wave runs.

The copies are the same repository migrations as Migrating Repositories. Each run is listed under Repositories › Migrations, with its logs.

Copy Into the Sandbox

Copy into the sandbox shows how much of the plan is copied, and how long copies take.

Each repository is one of:

• Copied
• Copied with a caveat
• Failed
• Copying
• Queued
• Not copied yet — not in a dry run, or still in a draft that has not started

When repositories are copying or queued, the page says when they should finish. That estimate treats each one as taking the median time of copies already measured, with GitHub working through five copies at a time in the sandbox organization. There is no expected finish until a copy has been measured.

Finished copies also show how long they took: the median, the time 90% of copies finish within, the longest copy, and the total, and how many took under 5 minutes, 5 to 15 minutes, 15 to 60 minutes, 1 to 3 hours, and 3 hours or more. The plan uses these times when it estimates how long a wave's move takes. See Schedule Waves.

The Runs

The sandbox runs for the plan's sources are listed oldest first. Each run shows its number and name, its status, how many of its repositories are copied, copied with a caveat, failed, copying, queued, or not copied yet, the projects it holds (largest first), and when it ran. A draft's repositories count as not copied yet. Open the run under Repositories › Migrations for its logs.

Copy What Is Not Copied Yet

Copy the N not copied yet does not start the copies. It saves draft runs for repositories that are not copied yet and that no run already holds. N is that count. CodeCargo saves one draft at a time and keeps going until every repository it can copy is in a draft.

• One source organization at a time, in the plan's order of sources. A later source waits until the earlier one has nothing left to draft.
• At most 2,500 repositories in a draft.
• A project's repositories stay in the same draft when they fit.

Each draft is named Dry run: and the source, with a number after the name when that name is already taken. Names are the ones a migration's preview would use. When repositories in a source would share a GitHub name, the project's name is put in front.

A repository the migration cannot take now is left out and listed:

• It was migrated already
• It has no commits
• Its name is taken in the sandbox organization, or two repositories would still get the same name

If the migration refuses a draft, the page reports that and skips that part, so the next part can still be drafted. Saving a draft does not change the plan. Repositories a draft holds are not drafted again, and they still count as not copied yet until a copy starts.

Open each draft under Repositories › Migrations and start it there. Starting asks for the tokens that migration needs and runs the pre-migration checks, the same as any other draft. See Creating a Migration. Delete a draft you do not want, and its repositories can be drafted again.

If the plan changed, or the repositories left to copy are not the ones the page showed, the copy does not start. Check the list and try again.

Keep Copies Fresh

Open Keep copies fresh from Dry run to see which copies have changed at the source since they were copied. Changed repositories are grouped by wave and by project. Each wave shows how many changed, the day the wave moves, and how long copying them again would take in the sandbox. Repositories that are not in a wave are listed on their own.

CodeCargo reads an Azure DevOps repository's branches, tags, and open pull requests before the copy is made, then compares that record with the source. A repository that is Copied or Copied with a caveat counts as changed when, since the copy, a branch or tag was added, deleted, or moved, or a pull request was opened, closed, reopened, or pushed to. Failed copies are left out. Open a repository on Plan Repositories to see those counts.

The page also shows how the comparisons are going:

• Compared with the source
• Could not read the source
• Not compared yet
• Cannot be compared, because nothing was recorded of the source before the copy

The oldest comparison is shown too. CodeCargo runs the comparisons on its own. A copy that was not compared, or cannot be compared, does not show as changed, so you have not confirmed it is still current.

Resolve Special Cases

Resolve special cases groups what the dry run did not copy cleanly, in the order you work them. Each group lists its categories, with a count and the first five repositories.

• Needs a fix at the source, then a retry — fix the repository in the source, then retry
• Can't be imported — the importer cannot take these
• A retry should work
• Copied with a caveat — the copy finished, but Git LFS objects were not copied, or a file was over the push limit

Retry

Retry starts that category's failed repositories in a run again, the same way Retry does on the migration run. It is offered while the run is checking or running, and after the run finishes with failures or is stopped. A run that cannot take a retry now says so.

Projects, Warnings, and Git LFS

Projects with failed copies are listed with the most failures first. Each one shows how many need a fix, cannot be imported, or should be retried.

The page also lists the importer's warnings and how many repositories each one applies to, and how many repositories use Git LFS. The importer never copies Git LFS objects. After the copy, fetch them and push them, as in After the Migration.