Migrating from GitLab
On This Page
This document provides an overview of how to migrate from GitLab to CircleCI.
|Tips provided by ImagineX Consulting|
Source control setup
If you are using GitLab’s SCM, you will first need to migrate your source code to GitHub or BitBucket. See the following for details on how to import your code:
Following are the steps required for using the git command line tool to import your GitLab repo into GitHub Enterprise:
Create an empty repository on your GitHub Enterprise instance.
Create a bare clone of your GitLab.com repository on your local machine, fetching all remote tags (refs/tags/*) and copying all remote branch heads (refs/heads/\*) directly to their corresponding local branch heads:
git clone email@example.com:[owner]/[repo-name].git --bare
Add your GitHub Enterprise repository as a remote reference in your local clone:
cd [repo-name] git remote add enterprise git@[hostname]:[owner]/[repo-name].git
Push all local references (refs/\*) up to your remote GitHub Enterprise repository:
git push enterprise --mirror
If you need to export other GitLab artifacts, follow the GitLab documentation on exporting a project.
Once you have imported your code into GitHub or BitBucket, you can start creating a project in CircleCI using the Getting Started guide.
If you are using GitLab’s CI/CD, you will need to migrate your build configuration. On GitLab, the build configuration is defined in a file called
.gitlab-ci.yml in the root directory of your source code repository. If you use shell scripts to perform your build, you can reuse those scripts in CircleCI.
First, create a CircleCI build configuration file. In the root directory of your source code repository, create a folder named
.circleci and create a file in that folder named
config.yml. Next, follow the CircleCI documentation here to learn how to configure the
The GitLab and CircleCI configurations will be different. It may be helpful to have both GitLab and CircleCI reference documentation open side-by-side to help with the conversion of the build steps:
Defining a job that executes a single build step
Specify a Docker image to use for a job.
Define a multi-stage build pipeline. Job1 and Job2 run concurrently. Once they’re done, Job3 runs. Once Job3 is done, Job4 runs.
Execute jobs on multiple platforms. GitLab uses tags to identify build runners. CircleCI provides all major OSes and Docker and must explicitly set in config. See our execution environments documentation for more information.
For larger and more complex build files, we recommend moving over the build steps in phases until you get comfortable with the CircleCI platform. We recommend this order:
Help make this document better
This guide, as well as the rest of our docs, are open source and available on GitHub. We welcome your contributions.
- Suggest an edit to this page (please read the contributing guidefirst).
- To report a problem in the documentation, or to submit feedback and comments, please open an issue on GitHub.
- CircleCI is always seeking ways to improve your experience with our platform. If you would like to share feedback, please join our research community.
Our support engineers are available to help with service issues, billing, or account related questions, and can help troubleshoot build configurations. Contact our support engineers by opening a ticket.
You can also visit our support site to find support articles, community forums, and training resources.
CircleCI Documentation by CircleCI is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.