Migrate from Bamboo

You can migrate from Atlassian Bamboo to GitLab CI/CD by converting Bamboo Specs YAML configurations exported from the Bamboo UI or stored in Spec repositories.

Key migration considerations

Configuration examples

Bamboo Specs export

The following examples show a Bamboo Specs YAML export from the UI and its GitLab CI/CD equivalent.

version: 2
plan:
  project-key: AB
  key: TP
  name: test plan
stages:
  - Default Stage:
      manual: false
      final: false
      jobs:
        - Default Job
Default Job:
  key: JOB1
  tasks:
  - checkout:
      force-clean-build: false
      description: Checkout Default Repository
  - script:
      interpreter: SHELL
      scripts:
        - |-
          ruby -v  # Print out ruby version for debugging
          bundle config set --local deployment true  # Install dependencies into ./vendor/ruby
          bundle install -j $(nproc)
          rubocop
          rspec spec
      description: run bundler
  artifact-subscriptions: []
repositories:
  - Demo Project:
      scope: global
triggers:
  - polling:
      period: '180'
branches:
  create: manually
  delete: never
  link-to-jira: true
notifications: []
labels: []
dependencies:
  require-all-stages-passing: false
  enabled-for-branches: true
  block-strategy: none
  plans: []
other:
  concurrent-build-plugin: system-default

---

version: 2
plan:
  key: AB-TP
plan-permissions:
  - users:
    - root
    permissions:
    - view
    - edit
    - build
    - clone
    - admin
    - view-configuration
  - roles:
    - logged-in
    - anonymous
    permissions:
    - view
...

default:
  image: ruby:latest

stages:
  - default-stage

job1:
  stage: default-stage
  script:
    - ruby -v  # Print out ruby version for debugging
    - bundle config set --local deployment true  # Install dependencies into ./vendor/ruby
    - bundle install -j $(nproc)
    - rubocop
    - rspec spec

Jobs and tasks

In both GitLab and Bamboo, jobs in the same stage run in parallel, except where there is a dependency that needs to be met before a job runs.

The number of jobs that can run in Bamboo depends on availability of Bamboo agents and Bamboo license size.

With GitLab CI/CD, the number of parallel jobs depends on the number of runners integrated with the GitLab instance and the concurrency set in the runners.

version: 2
#...

Default Job:
  key: JOB1
  tasks:
  - checkout:
      force-clean-build: false
      description: Checkout Default Repository
  - script:
      interpreter: SHELL
      scripts:
        - |-
          ruby -v
          bundle config set --local deployment true
          bundle install -j $(nproc)
      description: run bundler
other:
  concurrent-build-plugin: system-default

job1:
  script: "bundle exec rspec"

job2:
  script:
    - ruby -v
    - bundle config set --local deployment true
    - bundle install -j $(nproc)

Container images

The following examples show how the Bamboo docker keyword translates to the GitLab image keyword.

version: 2
plan:
  project-key: SAMPLE
  name: Build Ruby App
  key: BUILD-APP

docker: alpine:latest

stages:
  - Build App:
      jobs:
        - Build Application

Build Application:
  tasks:
    - script:
        - # Run builds
  docker:
    image: alpine:edge

default:
  image: alpine:latest

stages:
  - build

build-application:
  stage: build
  script:
    - # Run builds
  image:
    name: alpine:edge

Variables

The following examples show the syntax differences for defining and accessing variables.

variables:
  username: admin
  releaseType: milestone

Default job:
  tasks:
    - script: echo '$bamboo_username is the DRI for $bamboo_releaseType'

variables:
  DEFAULT_VAR: "A default variable"

job1:
  variables:
    JOB_VAR: "A job variable"
  script:
    - echo "Variables are '$DEFAULT_VAR' and '$JOB_VAR'"

Conditions and triggers

These examples show how Bamboo conditions and triggers convert to GitLab rules.

tasks:
  - script:
      scripts:
        - echo "Hello"
      conditions:
        - variable:
            equals:
              planRepository.branch: development

triggers:
  - polling:
      period: '180'

job:
  script: echo "Hello, Rules!"
  rules:
    - if: $CI_COMMIT_REF_NAME == "development"

workflow:
  rules:
    - changes:
        - .gitlab/**/**.md
      when: never

Artifacts

You can define job artifacts using the artifacts keyword in both GitLab and Bamboo.

version: 2
# ...
Build:
  # ...
  artifacts:
    - name: Test Reports
      location: target/reports
      pattern: '*.xml'
      required: false
      shared: false
    - name: Special Reports
      location: target/reports
      pattern: 'special/*.xml'
      shared: true

Test app:
  artifact-subscriptions:
    - artifact: Test Reports
      destination: deploy

# ...
Build:
  # ...
  tasks:
    - artifact-download:
        source-plan: PROJECTKEY-PLANKEY

stages:
  - build

pdf:
  stage: build
  script: #generate XML reports
  artifacts:
    name: "test-report-files"
    untracked: true
    paths:
      - target/reports

Caching

In Bamboo, Git caches can be used to speed up builds. Git caches are configured in Bamboo administration settings and are stored either on the Bamboo server or remote agents.

GitLab supports both Git caches and job cache. Caches are defined for each job using the cache keyword:

test-job:
  stage: build
  cache:
    - key:
        files:
          - Gemfile.lock
      paths:
        - vendor/ruby
    - key:
        files:
          - yarn.lock
      paths:
        - .yarn-cache/
  script:
    - bundle config set --local path 'vendor/ruby'
    - bundle install
    - yarn install --cache-folder .yarn-cache
    - echo Run tests...

Deployments

The following examples show how to convert Bamboo deployment projects to GitLab deployment jobs.

deployment:
  name: Deploy ruby app
  source-plan: build-app

release-naming: release-1.0

environments:
  - Production

Production:
  tasks:
    - # scripts to deploy app to production
    - ./.ci/deploy_prod.sh

deploy-to-production:
  stage: deploy
  script:
    - # Run Deployment script
    - ./.ci/deploy_prod.sh
  environment:
    name: production

release_job:
  stage: release
  image: registry.gitlab.com/gitlab-org/cli:latest
  rules:
    - if: $CI_COMMIT_TAG                  # Run this job when a tag is created manually
  script:
    - echo "Building release version"
  release:
    tag_name: $CI_COMMIT_TAG
    name: 'Release $CI_COMMIT_TAG'
    description: 'Release created using the CLI.'

Security scanning

Bamboo relies on third-party tasks provided in the Atlassian Marketplace to run security scans.

GitLab provides security scanners to detect vulnerabilities in all parts of the SDLC. You can add these scanners in GitLab using templates, for example to add SAST scanning to your pipeline:

include:
  - template: Jobs/SAST.gitlab-ci.yml

You can customize the behavior of security scanners by using CI/CD variables.

Secrets management

Secrets management in Bamboo is handled using shared credentials, or with third-party applications from the Atlassian marketplace.

For secrets management in GitLab, you can use supported integrations for external services. These services securely store secrets outside of your GitLab project, though you must have a subscription for the service.

GitLab also supports OIDC authentication for other third-party services that support OIDC.

Additionally, you can make credentials available to jobs by storing them in CI/CD variables, though secrets stored in plain text are susceptible to accidental exposure. You should always store sensitive information in masked and protected variables, which mitigates some of the risk.

Create a migration plan

Before starting your migration, create a migration plan and answer these questions:

• What Bamboo Tasks are used by jobs today and what do they do?
• Do any tasks wrap common build tools like Maven, Gradle, or NPM?
• What software is installed on Bamboo agents?
• How are you authenticating from Bamboo (SSH keys, API tokens, or other secrets)?
• Are there credentials in Bamboo to access outside services?
• Are there shared libraries or templates in use?

Migrate from Bamboo to GitLab CI/CD

Prerequisites:

• You must have a GitLab instance set up and configured.
• You must have runners available.

To migrate from Bamboo:

1. Audit your Bamboo configuration:

   • Export your Bamboo projects/plans as a YAML Spec from the Bamboo UI.
   • List all Bamboo tasks used in your jobs (for example, Maven, Docker, SCP).
   • Document software versions installed on each Bamboo agent.
   • Identify all shared credentials and their usage.

2. Migrate your source code repositories to GitLab:

   • Use the available importers to automate mass imports from external SCM providers.
   • Import repositories by URL for individual repositories.

3. Set up GitLab runners with equivalent software:

   • Install the same software versions that exist on your Bamboo agents.
   • For complex agent setups, create custom Docker images with your required tools.
   • Test that runners can execute your build commands successfully.

4. Convert Bamboo Specs to .gitlab-ci.yml files:

   • Replace Bamboo plan structure with GitLab stages and jobs.
   • Convert ${bamboo.variableName} syntax to $VARIABLE_NAME.
   • Replace Bamboo-specific variables like ${bamboo.planKey} with GitLab equivalents like $CI_PIPELINE_ID.
   • Remove Bamboo checkout tasks. GitLab automatically checks out your source code at the start of each job.

5. Migrate artifact handling:

   • Remove Bamboo artifact-subscriptions and artifact-download configurations.
   • Use automatic artifact inheritance between stages.
   • Update artifact paths to match your GitLab job structure.

6. Convert Bamboo deployment projects:

   • Move deployment tasks from separate Bamboo deployment projects into your main .gitlab-ci.yml file.
   • Replace Bamboo environments with GitLab environments.
   • Use cloud deployment templates for common deployment patterns.
   • Configure the GitLab agent for Kubernetes if deploying to Kubernetes.

7. Migrate secrets and credentials:

   • Use external secrets integrations or store credentials as masked and protected CI/CD variables.

8. Test and optimize your migrated pipelines:

   • Run test pipelines to verify functionality.
   • Add merge request integration to display pipeline results.
   • Optimize pipeline performance and create reusable templates.

Related topics

• Getting started guide
• CI/CD YAML syntax reference
• GitLab CI/CD variables
• Pipeline efficiency