The following example will remove the teams from the migration_archive.tar.gz file.
export GHEC_IMPORTER_ADMIN_TOKEN="xxxx"
ghec-importer prepare-archive -r teams migration_archive.tar.gz
The following example will import the migration_archive.tar.gz into the robandpdx-migaration5 org and enable actions on the repo. If there is a repo name conflict, if will be resolved by adding the source org name to the repo name as a prefix.
export GHEC_IMPORTER_ADMIN_TOKEN="xxxx"
ghec-importer import migration_archive.tar.gz -t "robandpdx-migaration5" -f actions -I --resolve-repository-renames org-prefix
ghec-importer provides several handy arguments depending on your purposes:
For the import command:
-D, --delete-importedprompts to delete migrated repositories after import, which is handy when performing dry runs.-f, --enable-features <features>: there are a few things to re-enable post-migration. This can enable three of those features: Actions, vulnerability-alerts, and automated security fixes.--resolve-repository-renames <string>: resolve repository name conflicts by renaming the repository name, can be org-prefix or guid-suffixI, --make-internalset repo visibility to internal on import.
For the delete-imported command:
-m, --models <models>comma-separated list of models to delete (repositories, teams) (default: "repositories")
By default ghec-importer will import the teams specifically added to the repository and additional org teams that have access to any migrated repository. In the context of GHEC-EMU, this might not be desirable. For example, some customers use migrations to re-organize team structure, and / or some may want to exclusively use IdP-managed teams and groups in their EMU enterprise.
Using the delete-imported command allows you to strip the repos' teams given the supplied migration GUID.
If using either ghec-importer or ECI, you have the option of supplying either tool a .csv file containing user mappings.
For example, let's say I have @jane-doe as a user on GHEC. As part of the migration, I'd want to ensure that @jane-doe's commits will be migrated and their metadata (their issues, comments, PRs, etc.) will remain largely as-is.
However, because @jane-doe will have a new user name in GHEC-EMU (i.e. @jane-doe_corp), we need to map and preserve their user data.
Creating a mappings .csv file and inputing it to either ECI or ghec-importer is a standard step during a migration exercise, and this issue will serve to track this particular step.
When using the ghec-importer CLI you'll follow this .csv format for your mapping file:
user,https://github.com/janedoe,https://github.com/janedoe_emu,RENAME
Here we see the mapping syntax in play: the leftmost column is the model type (i.e. user or repository, typically) and the rightmost column, RENAME, is the action to perform. For your purposes, you'll probably exclusively use RENAME when using your mapping file with ghec-importer. You can see a full list of mapping actions here.
Keep in mind that there user and repo metadata that GitHub's migration tools don't migrate. The key ones from this linked documentation are: webhooks, PATs, and SSH keys. Also, GitHub and OAuth applications will have to be recreated in the target org.