Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,640,527
Community Members
 
Community Events
196
Community Groups

Bamboo Docker Tag Best Practice

Hi,

I want to use Bamboo to start doing the building of  Docker images. But I would like a better tag than just giving everything the "latest". And I don't want to have to go back in and tag each. The Dockerfile will have a version of the application it is building in many cases.

What is the best methods found for a good version naming scheme when doing builds in Bamboo? Most of the images I currently am building, are based on applications that have their own versions, so I have been using those as the tag for the version, then an added increment number if I have rebuilt, but not updated the applications version. This increment I plan to use the Bamboo build number instead.

What is everyone else commonly doing?

Thanks,
Curtis

2 answers

1 accepted

0 votes
Answer accepted

I did as @Michel Vallée suggested. I created a inline script task to extract from the Dockerfile any and all variables I needed, setting them as Bamboo Variables through the InjectedVariablesTask. Then, use that variable in all places necessary, the primary one being in naming the new image, which is exactly as @Michel Vallée suggested:

my-registry/my-app-image:${bamboo.inject.VERSION}-${bamboo.buildNumber}

Here is an example of the inline script used to get the variable value from the Dockerfile:

grep "HTTPD_VERSION" Dockerfile | cut -d' ' -f 2 > properties.txt

This command saves  the value to a file named "properties.txt". The next step is then the "Inject Bamboo Variables" in which you provide it the "properties.txt" file as the properties file.

Then, anywhere you want to use the variable retrieved from the Dockerfile, you would do:

${bamboo.inject.HTTPD_VERSION}

 If you want this variable to be available to another job in a later stage or release, just select "Result" in the "Inject Bamboo Variable" task.

I just signed up yesterday so I'm curious as to how I can get all of the products that are compatible. How many are available exactly? I haven't even seen Bamboo yet!

We use Jira, Confluence, Bitbucket and Bamboo. They all work together and easily integrate to help give context in each of them. With Bamboo, we can easily see with each build, who executed it and what changes/commits existed new to that build from the previous build.

Like Jlk likes this

Having same problem.  Want the version to be in the Dockerfile but also part of the tag.

Not sure how to have Bamboo retrieve the version from the Dockerfile and use it as part of a variable.

I was able to run a script to export it to a file then use the InjectVariablesTask to retrieve back out.  However, my understanding is that the variable is then only available on the agent or in deployment plans.  It is NOT available in a follow-up task in the same plan.

I.e. I need in the step right after where I use the DockerBuildImageTask which is where I want to specify the tag to use.

I want to use the format:

my-registry/my-app-image:${bamboo.inject.VERSION}-${bamboo.buildNumber}

If you set the scope for the InjectVariablesTask to not local, it will make it available in other jobs in later Stages in the same Plan.

I'll split my stage in two to see if that helps.  Thanks!

Just out of curiosity, did you get your desired setup working? Were you able to pass the variable to the second stage?

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events