Migrating from AWS

This document provides an overview of how to migrate from AWS CodeCommit to CircleCI.

Tips provided by ImagineX Consulting

Source Control Setup

If you are using AWS Code Commit, you will first need to migrate your source code to GitHub or BitBucket. See the following for details on how to import your code:

GitHub Enterprise

Following are the steps required for using the git command line tool to import your code into GitHub Enterprise:

  1. Create an empty repository on your GitHub Enterprise instance.

  2. Create a bare clone of your external 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.

    untranslated: true- git clone https://external-host.com/extuser/repo.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

Once you have imported your code into GitHub or BitBucket, you can start creating a project in CircleCI using the https://circleci.com/docs/2.0/getting-started/[Getting Started guide].

== Build Configuration

Next, you will need to migrate your build configuration. On AWS CodeBuild, the build configuration is either defined in the web interface or in a file called `buildspec.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 `config.yml` file.

The AWS CodeBuild and CircleCI configurations will be different. It may be helpful to have both AWS DevOps and CircleCI reference documentation open side-by-side to help with the conversion of the build steps:

* https://docs.aws.amazon.com/codebuild/latest/userguide/build-spec-ref.html[AWS CodeBuild Build Spec Reference]

* https://circleci.com/docs/2.0/configuration-reference/[CircleCI YML Reference]

Some differences that are worth calling out:

[cols=2*, options="header", stripes=even]
| AWS | CircleCI

2+h| Define a job that executes a single build step.


phases: build: commands: - ./execute-script-for-job1.sh


jobs: job1: steps: - checkout - run: "execute-script-for-job1"

2+h| Specify a docker image to use for a job.


phases: install: runtime-versions: nodejs: 10


jobs: job1: docker: - image: node:10 auth: username: mydockerhub-user password: $DOCKERHUB_PASSWORD # context / project UI env-var reference

2+h| Define a multi-stage build pipeline. Job1 and Job2 run concurrently. Once they’re done, Job3 runs. Once Job3 is done, Job4 runs. An AWS CodeBuild project runs all commands sequentially. If you are running concurrent commands, you’re probably using CodePipeline and multiple CodeBuild projects.


CodePipeline Project 1

phases: build: commands: - make build dependencies

CodePipeline Project 2

phases: build: commands: - make build artifacts

CodePipeline Project 3

phases: build: commands: - make test

CodePipeline Project 4

phases: build: commands: - make deploy


version: 2 jobs: job1: steps: - checkout - run: make build dependencies job2: steps: - run: make build artifacts job3: steps: - run: make test job4: steps: - run: make deploy

workflows: version: 2 jobs: - job1 - job2 - job3: requires: - job1 - job2 - job4: requires: - job3

2+h| Execute jobs on multiple platforms. An AWS CodePipeline project can target a single platform only. If you are targeting multiple platforms, you’re probably using CodePipeline and multiple CodeBuild projects. CircleCI provides executors for docker, Linux and MacOS that can be combined in a single build definition.


Environments are selected in the CodeBuild

web console or defined in a project

configuration file:

{ "name": "linux project", "environment": { "type": "LINUX_CONTAINER" } }

{ "name": "windows project", "environment": { "type": "WINDOWS_CONTAINER" } }


jobs: ubuntuJob: machine: image: ubuntu-1604:201903-01 steps: - checkout - run: echo "Hello, $USER!" osxJob: macos: xcode: 11.3.0 steps: - checkout - run: echo "Hello, $USER!"

2+h| Cache dependencies.


If custom cache is enabled in the web

console, CLI or CloudFormation, cache

locations can be specified in the

buildspec.yml file:

phases: build: commands: npm install cache: paths: - 'node_modules/*/'


jobs: job1: steps: - restore_cache: key: source-v1-< .Revision >

  • checkout

  • run: npm install

  • save_cache: key: source-v1-< .Revision > paths:

  • "node_modules"


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:

. Execution of shell scripts and Docker compose files
. https://circleci.com/docs/2.0/workflows/[Workflows]
. https://circleci.com/docs/2.0/artifacts/[Artifacts]
. https://circleci.com/docs/2.0/caching/[Caching]
. https://circleci.com/docs/2.0/triggers/#section=jobs[Triggers]
. https://circleci.com/docs/2.0/optimizations/#section=projects[Performance options]

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.