Bamboo Concepts

Internal

• Bamboo

Project

Projects allow you to easily group and identify plans which are logically related to each other.

Build Plan

A build plan. It defines everything Bamboo needs to know to about the build process. Each plan has a Default job when it is created. More advanced configuration options, including those for plugins, and the ability to add more jobs will be available after creating this plan. A plan belongs to a project.

Plan Operations

Stage

Each stage within a plan represents a step within your build process. A stage may contain one or more jobs which Bamboo can execute in parallel.

Job

Bamboo Documentation - Jobs and Tasks

Each plan has a default job when it is created. A job has multiple tasks. More than one job can be added to a plan.

Task

Bamboo Documentation - Jobs and Tasks

A task is an operation that is run on a Bamboo working directory using an executable, such as a script, shell command, ant task or Maven goal.

This is how you create a typical task for the Default job:

Operations - Create a Typical Task

Artifact

Artifacts are the result of build plans.

Create artifact:

Name: Clover Report (System)
Location: target/site/clover
Copy pattern: **/*.*
Not shared, not required.

Create artifact:

Name: libs
Location: build/libs
Copy pattern: **/*.jar
Shared, required.

Miscellaneous

Use Clover to collect Code Coverage for this build.

Clover is already integrated into this build and a clover.xml file will be produced.

Clover XML Location: target/site/clover/clover.xml

Build

Build Isolation

Builds are normally run in the agent's native operating system ("Agent environment" choice). The build could be run in an isolated and controlled environment with Docker ("Docker container" option). The build isolation can be changed after a plan is defined with Plan -> Actions: Configure Plan -> Select Job -> "Docker" tab.

Executable

https://confluence.atlassian.com/bamboo0606/bamboo-faq/glossary/executable

Repository

One or more repositories can be added to a plan. The repositories will then be available to every job in the plan. The first repository in the list is the plan’s default repository. The repositories to which a trigger applies can be selected in respective trigger's configuration.

Repository Operations

Repository Types

Git

In general, use Git repositories, which allow SSH authentication.

GitHub

GitHub won't allow SSH authentication.

Variables

Bamboo Variables

Situate this: Setting and Environment Variable on a Task.

Global Variables

Global variables are defined across the entire Bamboo instance, and have the same static value for every plan that is built by Bamboo. They can be accessed using ${bamboo.globalvarname}.

For task configuration fields, use the syntax ${bamboo.myvariablename}. Bamboo also supports nested variables. For instance, if you set variableName = world, and variable.value = Hello ${bamboo.variableName}, Bamboo will resolve it as Hello world.

For inline scripts, a variable that has been defined as MY_VARIABLE_NAME is exposed as a shell environment variable that can be accessed using the syntax $bamboo_MY_VARIABLE_NAME (Linux/Mac OS X) or %BAMBOO_MY_VARIABLE_NAME% (Windows).

This is how to define a global variable:

Define a Global Variable

Plan Variables

A plan variable is defined for one specific plan, and has the same value every time that plan is built. To define a variable across all plans rather than a single plan, define a global variable.

A plan variable has precedence over a global variable with the same name.

This is how to define a plan variable:

Define a Plan Variable

Task Environment Variables

Values for task-specific environment variables can be defined when the task is created. The variable defined in the plan is injected without any name modifications (unlike global variables) in the environment of the task's executable.

Deployments

Deployment Project

Deployment Projects

A deployment project defines the build plan that produces the artifacts to be deployed, typically releases that have been built and tested and the environments the artifacts should be deployed into.

Deployment Environment

A deployment environment represents the servers or groups of servers where the artifacts are deployed to, and the deployment tasks. Environments have permissions that allow fine grained control of who can deploy, edit or view an environment and record the full history of releases deployed to it.

Release

A release is a snapshot of a set of artifacts, and its associated metadata such as commits, JIRA issues and the builds that were used to test it. As a release contains the information of the difference between itself and the release beforehand, it exposes changes between releases or between the software deployed on two different environments. Releases also track what environments they have been deployed to.