Bamboo Operations

From NovaOrdis Knowledge Base
Revision as of 07:38, 23 January 2019 by Ovidiu (talk | contribs)
Jump to navigation Jump to search

Internal

Plan Operations

Create a Plan

A plan can be created and configured any time after creation of the enclosing the project:

Projects -> the project in question -> Upper Blue Menu -> Create -> Create plan.

The "Configure Plan" view is exposed.

Configure a Plan

Projects -> the project in question -> Select the Plan -> Actions drop down -> Configure plan.

Configuration options when creating the plan:

  • Project
  • Plan name
  • Plan key
  • Plan description
  • Plan access - allow all users to view this plan
  • Link repository to new build plan -> Link new repository. The process is similar to the one described in the "Repository Operations" section.

The repository can be specified during the plan creation process, or later.

Repository Operations

To add a repository to a plan:

Project -> Plan -> Actions: Configure plan -> "Repositories" tab -> Add Repository -> "Git" repository (see difference between Git and GitHub repositories)

Display name: up.plat-svc.cryptm. Use the name of repository.

Repository URL: git@github.com:test-inc/up.plat-svc.cryptm.git

Authentication type: SSH private key

Use shared credentials, shared credentials: Github Bamboo User SSH

Branch: develop (if nothing is specified, it assumes "master")

Test Connection

Repository access: Allow all users to reuse the configuration of this repository.

Save Repository.

Create a Typical Task

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

Source Code Checkout

Tasks -> Add task -> Source Control -> Source Code Checkout.

Task description: "GitHub checkout"

Repository: pick from pre-configured, see repository.

Checkout Directory: this is optional, to specify an alternative to the default directory.

Force clean build - typically not selected. Removes the source directory and checks it out again prior to each build. This may significantly increase build times.

Build Command

Tasks -> Add task -> Command.

The configuration of the build command is different in the case of library and of a service that deploys as a Docker container.

Building a Library

Task description: "Gradle build and publish command"

Executable: Gradle4

Argument:

clean build publish

Building a Service

The service does not. publish a JAR in the Maven repository, it builds a container and push it into a Docker registry instead.

Task description: "Gradle docker build"

Executable: Gradle4

Argument:

-Dorg.gradle.project.BAMBOO_BUILD_NUMBER=${bamboo.buildNumber} clean docker

The service build needs an additional docker build task:

Docker Build Script

This is only required for service builds:

Script task.

Task description: "Docker build script"

Interpreter: Shell

Script location: Inline

Script body:

#!/usr/bin/env bash

MAVEN_GROUP_NAME=$1
APPLICATION_NAME=$2
GIT_BRANCH=$3
REVISION_NUMBER=$4
BAMBOO_BUILD_NUMBER=$5

REGISTRY_URL=144446676909.dkr.ecr.us-west-2.amazonaws.com

echo "MAVEN_GROUP_NAME=${MAVEN_GROUP_NAME}"
echo "APPLICATION_NAME=${APPLICATION_NAME}"
echo "GIT_BRANCH=${GIT_BRANCH}"
echo "REVISION_NUMBER=${REVISION_NUMBER}"
echo "BAMBOO_BUILD_NUMBER=${BAMBOO_BUILD_NUMBER}"
echo "REGISTRY_URL=${REGISTRY_URL}"

echo "logging into ECR ..."

$(aws ecr get-login --no-include-email --region us-west-2)

#
# debugging
#
docker images

#
# clean the repository
#
# docker rmi --force $(docker images --format "{{.ID}}")

source_image_tag=${MAVEN_GROUP_NAME}/${APPLICATION_NAME}:latest
target_image_tag=${REGISTRY_URL}/${MAVEN_GROUP_NAME}/${APPLICATION_NAME}:${GIT_BRANCH}-${BAMBOO_BUILD_NUMBER}
target_image_tag_latest=${REGISTRY_URL}/${MAVEN_GROUP_NAME}/${APPLICATION_NAME}:latest

echo "tagging the latest image ${source_image_tag} as ${target_image_tag} ..."

docker tag ${source_image_tag} ${target_image_tag} || { echo "docker tag failed" 1>&2; exit 1; }

echo "pushing image ${target_image_tag} ..."

docker push ${target_image_tag} || { echo "docker push failed" 1>&2; exit 1; }

echo "tagging the latest image ${source_image_tag} as ${target_image_tag_latest} ..."

docker tag ${source_image_tag} ${target_image_tag_latest} || { echo "docker tag failed" 1>&2; exit 1; }

echo "pushing image ${target_image_tag_latest} ..."

docker push ${target_image_tag_latest} || { echo "docker push failed" 1>&2; exit 1; }

Argument:

playground.aws.example myapp ${bamboo.repository.git.branch} ${bamboo.repository.revision.number} ${bamboo.buildNumber}

Task Environment Variables Support

Environment variables: This allows setting task environment variables, which will propagate to the task environment. The syntax is presented below:

MY_TEST_ENVIRONMENT_VARIABLE="something"

If, for example, we are building and testing Spring applications, that value will automatically propagate to the Spring runtime as "my.test.enviornment.variable" and can be used in placeholders.

JUnit Parser

Tasks -> Add task -> JUnit Parser.

Task description: "Parses JUnit test results"

Specify custom result directories:

**/test-results/test/*.xml

This value seems different from default. It works, but why different?

Clover File Converter Command

Tasks -> Add task -> Command.

Task description: "Clover file converter"

Executable: CloverConverter

Argument:

clean build publish

Sonarqube Command

Tasks -> Add task -> Command.

Task description: "SonarQube"

Executable: Gradle4,

Argument:

sonarqube  -Dsonar.branch.name=${bamboo.repository.git.branch} -Dsonar.projectKey=up.plat-svc.cryptm  -Dsonar.organization=test-inc   -Dsonar.host.url=https://sonarcloud.io  -Dsonar.login=...

Variables

Variables operations.

Define a Plan Variable

TODO: https://confluence.atlassian.com/bamboo/defining-plan-variables-289276859.html

Define a Global Variable

https://confluence.atlassian.com/bamboo/defining-global-variables-289277112.html

This procedure defines a global variable:

Go to the Cog Wheel on the front page -> Global Variables -> Add.

Note that a MY_VARIABLE defined here will be exposed as bamboo_MY_VARIABLE in the tasks' shells. For more details see:

Global Variables

Deployment Operations

Deployment projects operations:

Configure a Deployment Project

1. Select a build plan.

2. Edit tasks

  • "Clean working directory" task.
  • Script:

Interpreter: Shell

Script location: Inline

#!/usr/bin/env bash

MAVEN_ARTIFACT_NAME=$1
DEPLOYMENT_ENVIRONMENT_NAME=$2
TARGET_AWS_CLUSTER=$3
BAMBOO_RELEASE_NAME=$4

REGISTRY_URL=144446676909.dkr.ecr.us-west-2.amazonaws.com
MAVEN_GROUP_NAME=playground.aws.example

echo "logging into ECR ..."

$(aws ecr get-login --no-include-email --region us-west-2)

source_image=${REGISTRY_URL}/${MAVEN_GROUP_NAME}/${MAVEN_ARTIFACT_NAME}
source_tag=${BAMBOO_RELEASE_NAME}
target_image=${REGISTRY_URL}/${MAVEN_GROUP_NAME}/${MAVEN_ARTIFACT_NAME}
target_tag=${DEPLOYMENT_ENVIRONMENT_NAME}

echo "tagging ${source_image}:${source_tag} as ${target_image}:${target_tag} ..."

docker tag ${source_image}:${source_tag} ${target_image}:${target_tag}

echo "pushing ${target_image}:${target_tag} ..."

docker push ${target_image}:${target_tag}

echo "updating AWS service ${MAVEN_ARTIFACT_NAME} on cluster ${TARGET_AWS_CLUSTER} ..."

aws ecs update-service --cluster ${TARGET_AWS_CLUSTER} --service ${MAVEN_ARTIFACT_NAME} --force-new-deployment

Arguments:

myapp dev01 cluster-dev01 ${bamboo.deploy.release}

where ${bamboo.deploy.release} is substituted by Bamboo at runtime with release name, which usually is similar to "develop-699".

Note that the image to be deployed in the target cluster, in this case 144446676909.dkr.ecr.us-west-2.amazonaws.com/playground.aws.example/myapp:develop-699, must be previously built by the Bamboo as part of a build plan.

A typical build plan driven by Gradle ends up in a command similar to:

gradle -Dorg.gradle.project.BAMBOONUM=699 clean docker

Gradle can use a Docker plugin such as com.palantir.docker.