Skip to main content

CodeCommit to Gitlab Migration

· 4 min read
Bob Devitt
Bob Devitt
Author

After AWS announcing that CodeCommit would no longer be accepting new customers back in July, it became evident that migrating source control from AWS would eventually become imperative.

Since then, I started my Homelab project which involves self-hosting a Gitlab repo and push-mirroring it to a native git repository on an AWS EC2 instance for backup purposes (which itself is also backed up.)

It has made more sense to me, in my particular environment, to depend less on 3rd party Software-as-a-Service for critical systems.

A simple mini PC, such as a Beelink1, was enough to get me up and running with a minimal Gitlab config.

Migrating via mirror and push​

In the AWS Blog announcing the end of CodeCommit, it additionally provides some resources for migration using the Gitlab import methods.

Since my repos on CodeCommit were private and secured with SSH keys, I found it easier to migrate via command line than to mess around with unnecessarily importing AWS keys in Gitlab.

A migration is as simple as mirroring the AWS CodeCommit repo first, then pushing it to Gitlab. By default, Gitlab does not require creating the repo first.

note

This guide assumes you have access to both AWS CodeCommit and your Gitlab instance from the same terminal.

Mirroring AWS CodeCommit​

If you clone a remote repo without the --mirror option, git will not track all of the branches that may exist. It will only checkout HEAD first, and depend on the user entering additional checkout commands to switch and track branches.

This makes sense if we are simple contributors, however when migrating we need to pull all the data. You may have found some over-complicated scripts on Stackoverflow that loop over branch listings and execute checkout on them. Like me, you must have thought there must be a simpler way. This is the inspiration for this post.

The general concensus (including official instructions by Github on backing up a repo) is to use the --mirror option.

However by default, --mirror creates a bare repo without a working tree. In order to push to Gitlab, we need to re-enable the working tree by disabling the bare option and doing a hard reset.

Here is an example:

# create an empy directory with your repo's name
mkdir your-repo
cd your-repo

# create a mirror into the .git directory (as it is in a non-bare working tree configuration)
git clone --mirror ssh://git-codecommit.region.amazonaws.com/v1/repos/your-repo .git

# convert the mirror back to a working-tree configuration in preparation for pushing to Gitlab
git config set core.bare false

# git is now mis-interpreting our newly empty working-tree as deleting everything in HEAD.  Let's reset.
git reset --hard

# we can now verify status is nominal, and all remote branches are now tracked locally (no remote refs with red text)
git status
git branch -a

Pushing to Gitlab​

Now that we have a complete local repo, we can now push all branches to Gitlab.

First we must switch our remote "origin" to a new location on our Gitlab instance. Then we can push all our branches.

Remember, Gitlab by default allows pushes to create new repos automatically.

# change our remote origin from AWS to a new location on Gitlab
git remote set-url origin ssh://git@gitlab.your-url.com/organization/subdirectory/your-repo.git

# create a new Gitlab repo and push all branches
git push --all

And finito! Gitlab should respond with the new project URL, and all branches that were created and pushed.

Anyone else using the old remote origin should now switch to the new one using the above git remote command.

Closing Thoughts​

This process should work between any git host, with the potential caveat of having to create the repo first before pushing. Not having to do so with Gitlab is a nice little feature.

If you are interested in setting up mirroring on Gitlab to a git server on an Amazon EC2 instance I will outline the basics here (with a potential blog post in the future):

  • Setup a new git server on your EC2 instance using the official instructions
  • mkdir your-repo.git on the new git server
  • Create an SSH key for the git user on the EC2 instance
  • Create a push mirror with the URL and SSH key in your Gitlab repo's "repository" settings.

Disclosures

As an Amazon Associate I earn from qualifying purchases.

Amazon referral links are only located in the footnotes.

Earnings help me to continue writing by funding critical resources like coffee.

Footnotes​

  1. (referral link) Beelink N100 https://amzn.to/3BmPn6j ↩