nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How do you get the version number of your pom as a variable for use in the release name of a deployment?

unknown

Hi,

here is what I want to do: I have a deployment project. I created a new release with this deployment project. The version scheme of the release is "${bamboo.planName} #${bamboo.buildNumber}". My project is being build with maven and I want the release named something like this: "${bamboo.planName} ${bamboo.maven.version}#${bamboo.buildNumber}"

I'm using the Maven POM Value Extractor Plugin, so all I need is, to have the ${bamboo.maven.version} variable available in the release versioning naming scheme. Currently there are only predefined variables and plan variables available. So another option could be dynamic plan variable creation in the build task.

I don't want to manually change the version number. This should be automatic. Is there a solution/workaround/plugin to solve this problem? Is it even possible to achieve this with a plugin?

Accepted answers

Guillaume Dupér1

OK Got it working !!!!

This is a resume of what is needed :

1- create Plan A that will build the application and deploy to nexus

Tasks:

1- build application

2- deploy to nexus

3- call PLANB via REST API and pass the variable bamboo.variable.version=${bamboo.maven.version}

i.e curl -X POST --user bambooUser:bambooPassword http://bamboo-server/rest/api/latest/queue/PROJECT_NAME-PLAN_NAME?executeAllStages=true&bamboo.variable.version=VERSION_NUMBER_PASSED_TO_SCRIPT

please NOTE: the variable name HAS TO start with bamboo.variable or else it will not work !

2- Create Plan B that will download from nexus the version you just passed to it via PLAN A and this will trigger an auto-deploy with the correct version number

Tasks:

1-download application from nexus

2- share war/ear artifact for deployment

Deployment task

1- get artifact

2- deploy artifact to tomcat or weblogic werver

There are multiple advantages of doing it like that :

1- you can reuse the PLANB to download and deploy ANY version you want to ANY environment you want and bamboo will have a trace of those version numbers (this is by running the PLAN B as custom build and change the version variable).

2- you can clone the PLAN A for any non-deployable project (for example a maven sub-project that you want to go to nexus , but not deploy it on any server).

This scenario could be really powerful and it as been tested on a test project (just got the answer from atlassian) , but I will implement it in a real project this week or next week, I'll let you know !

If you want more info, please let me know and I can post anything you need !

Since I only have 16 karma, I cannot post more than 1 comment a day (based on the error I got when I tried to reply in the same day) , then it can take some time to answer , but I'll do my best to post few things under the same answer...

I hope it helps you guys a lot !

please let me know if it helps you or not !

cheers

Guillaume

All comments

Joseph Earl

I agree.

Guillaume Dupér1

I have opened a ticket for this... for now it is between an atlassian employee and I , but I'll let you know if I find something...

I've tried many things and nothing worked...

I'Ve tried to use the inject plugin , but the variables don't get passed to other stages or the deployment projects.

I have also tried to call the deployment "build plan" passing the pom version as a variable using the REST API and the build plan gets the new variable , but not the deployment project linked to it.

I've tried to think about what if bamboo handles my release numbers ? NAHHH... I want the release to be determined in the build plan , but the deployment number is only avaible in the deployment project, then you cannot call release:prepare with the bamboo predetermined version number in the build plan.

Also bamboo does not make intelligent release numbers... like when I increase the minor number (in Major.Minor.Build) I want the build number to reset to 0 ... bamboo does not do that (maven does).

Anyway, if someone finds a way (even an hack) to do this, please let us know !

If my ticket gets opened publicly , I will include it here !

Guillaume

Joseph Earl

Great please do update us if you hear anything.

unknown

Since I prefer the great maven jgitflow plugin https://bitbucket.org/atlassian/maven-jgitflow-plugin to manage my maven releases and scm tagging I would prefer a genrel purpose solution for this, e. g. access a variable in release naming scheme, which was set in a task.

Guillaume Dupér1

This is exactly what I asked them : Is it possible to dynamically change the release number variables since using the inject plugin and the REST api is not working ?

If they provide us with a way to change the release variables dynamically , you will be able to determine the release number using anything you like (script, maven, jgitflow... anything) . You would just have to change the varaible number and pass it to the deployment process.

This would be nice , but let see what they answer...

unknown

Any news on this?

Guillaume Dupér1

I have BSP-11145 opened for this , but right now it is not public...

I've gave atlassian support all the screenshots they need , but I think it will take some time to fix it.

Right now, what I am doing is that I have a release plan which deploys automatically to dev and nexus which I don<t mind about the bamboo release number and I have another plan which downloads the right version (using a customized plan which is changing the variable deploy.version to what I want) and that build plans download the right version from nexus and deploys to the user acceptance environment with the right version number.

If you setup the plan variable manually , the deployment release will get updated , but right now it cannot be done automatically !

I'll keep you posted of any change !

Guillaume

Guillaume Dupér1

OK Got it working !!!!

This is a resume of what is needed :

1- create Plan A that will build the application and deploy to nexus

Tasks:

1- build application

2- deploy to nexus

3- call PLANB via REST API and pass the variable bamboo.variable.version=${bamboo.maven.version}

i.e curl -X POST --user bambooUser:bambooPassword http://bamboo-server/rest/api/latest/queue/PROJECT_NAME-PLAN_NAME?executeAllStages=true&bamboo.variable.version=VERSION_NUMBER_PASSED_TO_SCRIPT

please NOTE: the variable name HAS TO start with bamboo.variable or else it will not work !

2- Create Plan B that will download from nexus the version you just passed to it via PLAN A and this will trigger an auto-deploy with the correct version number

Tasks:

1-download application from nexus

2- share war/ear artifact for deployment

Deployment task

1- get artifact

2- deploy artifact to tomcat or weblogic werver

There are multiple advantages of doing it like that :

2- you can clone the PLAN A for any non-deployable project (for example a maven sub-project that you want to go to nexus , but not deploy it on any server).

If you want more info, please let me know and I can post anything you need !

I hope it helps you guys a lot !

please let me know if it helps you or not !

cheers

Guillaume

Robert Watkins

Yikes, that's clumsy. But based on my understanding, then yeah, that's what it takes.

Bamboo needs a lot more support for sharing artifacts of Maven builds; you shouldn't need to have your own repo for this sort of thing.

unknown

Thanks for the update!

Since I deploy to our enterprise repo, I will replace nexus with our repo and test this workflow against our setup. I'll keep you updated how it works.

unknown

Can't edit my comment....

Update:

I tried your suggested solution. Everything is getting built in my plan a and plan a trigger plan b correctly with the api call. The deployment project for plan b is also getting triggered, but the variable in the release versioning is not getting replaced. I have this "${bamboo.planName} ${bamboo.variable.version}" as version name.

Guillaume Dupér1

BY THE WAY : If you don't want to use nexus like I am doing... no problem... just use the artifact sharing between plans : https://confluence.atlassian.com/display/BAMBOO/Sharing+artifacts

I havn't tested it yet, because for me everything is going to nexus... but this should be a good solution if it works with REST API calls...

If anyone of you test it before me , please let me know if it works !

thanks

Guillaume

Guillaume Dupér1

Yeah, it sounds clumbsy, and I would have a lot prefered the inject plugin to handle that instead of having to call using the API... the ticket for the inject plugin is opened , then we will wait for this to have a better solution...

In the mean time : OLIVER:

Please ONLY USE bamboo.variable in your REST API call , nowhere else !

then when you call plan B you use curl -X POST ...... bamboo.variable.version=whatever

in your planB , create a PLAN variable called version (or the variable name you want) and assign it a dummy version number and in the build , if you want to see it , you refer to it by ${bamboo.version} and the same in your release variable.

in bamboo , you just use ${bamboo.version} and it should work...

If it doesn't please let me know (and send me the curl command you use and the metadata page screenshot of the plan B . The PLAN variable version in the metadata of PLANB should be changed from INITIALVALUE to whatever.

Don't forget I am using bamboo 5.1... I have tested it with 5.1 only since they have changed few things around this and it can have an impact on it.

I would like to know if it's working for anybody else using another version than 5.1

cheers

Guillaume

unknown

I created the plan variable and changed to variable name in release versioning scheme and now it works! Thank you for looking into this and for providing a workaround, Guillaume!

Gretchen

With the injection plugin you do have to retrieve in each stage to use it. nuisance but it does work. As long as the value in the txt file that contains your variable hasn't been changed it should work to retrieve it in each stage. (you don't have to repopulate the txt file just re capture the contents.

Guillaume Dupér1

Guys, I have good news !!

No more workaround !!

I am using bamboo 5.3 build 4101 - 09 Dec 13

and pom value extractor 1.3.0.

If you create a build plan and follow those simple steps , everything will work perfectly , no need for a work-around !

create a build plan.
add repository
checkout from repository
add pom value extractor task using the PLAN as the Variable TYPE to load your pom.xml version into variable "deploy.version"
Create deployment project based on this build plan
add environment and put release scheme as REL-${bamboo.deploy.version}
run build and voila ! you have deployed the version from your maven pom.xml.

Thanks to the maven pom extractor plugin !!

cheers

Guillaume

P.S. let me know if it works or not for you !!!

Bjarte Nilsen

Doesn not work for me. Variable not resolved to a value.

My Deploys are called "eployment: REL-${bamboo.deploy.version} on ..."

AF KL Customer

I have the same behaviour as Bjarte with pom value extractor 1.4.0. It seems that the scope of the variable is limited to the Build Plan and not the Deployment project

Andrew Pitt1

I think the problem is that the Deployment Project sees the "Plan" variables in the state that they were in then the source build BEGINS.

Try running your source build again and you should see the the variable ${bamboo.maven.version} resolves this time. The problem is, you will now have the ${bamboo.maven.version} value that was set during your LAST build.

For us, this is a problem, since our release build automatically increases the version in the pom.

This has the effect of each "Deployment" release being behind by a version (which is obviously bad).

Xabier Davila_paa7go

+1 for this. Build Plan variables should be available in the release naming scheme

Marimuthu Madasamy

This works but I used a different name in the Maven POM Value Extractor configuration than `deploy.version` since `deploy.version` is already an in-built Bamboo variable.

Radek Antoniuk

You can do that currently via bamboo inject from variables file I guess.

Rahul Ghadi

It does not work for me.

I can see in the LOG

NINJA_VERversion to 4.4.0.18-SNAPSHOT

even when i have set the varaible to NINJA_VER

When i access it using maven task

like ${bamboo.NINJA_VER} it gives output NULL.

Can you help me

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

bamboo