It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Inconsistency in Bamboo Variables bamboo.jira.userName

Xabier Davila May 05, 2014

Hi,

I order to be able to release from JIRA and directly from Bambooo, we've been using the following shell inline script to run in some of our plans:

...

if [ -n "${bamboo.version.name}" ]; then

  VERSION_NAME="${bamboo.version.name}"

else

  VERSION_NAME="${bamboo.jira.version}"

fi

...

All good up to here.

Today we've added the bit below, and our builds keep failing with bad substitution error message:

...

if [ -n "${bamboo.jira.username}" ]; then

  BUILD_USER="${bamboo.jira.username}"

else

  BUILD_USER="${bamboo.ManualBuildTriggerReason.userName}"

fi

...

Also tried the more obscure oneliner:

BUILD_USER="${bamboo.jira.username:-$(echo ${bamboo.ManualBuildTriggerReason.userName})}"

If I run the same code as a shell script (getting rid of the dots in the variable names) seems to work fine.

If I run a task with a plain script displaying the environment variables with env, I see those variables are not exported.

Any ideas on how to use BUILD_USER in my build scripts?

3 answers

1 accepted

1 vote
Answer accepted
Ron Chan May 05, 2014

Xabier,

Can you expand a bit on the workflow of the part of your script that does work. What are you trying to achieve? Please clarify "release from JIRA and directly from Bamboo".

Xabier Davila May 05, 2014

Hi, this bit belongs to the tag release build script.

I need those variables to add info to the build artifact: the user that built the binary and the version of the binary (tag name, etc).

I can trigger the build either from JIRA (relase version) or Bamboo (run customized)

- Bamboo directly: the version is typed as value for a custom variable. The user that triggers the build is picked by ${bamboo.ManualBuildTriggerReason.userName} variable

- Releasing a version from JIRA: Values are set in the variables ${bamboo.jira.username} and ${bamboo.jira.version}

This was (is) working fine if I just use the verison if block, failing if I add the username one.

Thanks

Xabier Davila May 13, 2014

Maybe I should reformulate the question:

How can I use in my build scripts the username that has triggered a build, regardless this is done manually in Bamboo or via JIRA > relese version

Ron Chan May 13, 2014

In response to this particular question, you can have bamboo task run something like:

build.sh ${bamboo.jira.username}

then from within build.sh, you can reference username value as $1

Xabier Davila May 13, 2014

Hi Ron,

This will work *only* when the build is triggered from JIRA and will fail with a "bad substitution" exception when the build is triggered manually.

As per above, this is what I was trying to do:

if [ -n "${bamboo.jira.username}" ]; then
 
  BUILD_USER="${bamboo.jira.username}"
 
else
 
  BUILD_USER="${bamboo.ManualBuildTriggerReason.userName}"
 
fi

build.sh ${BUILD_USER}

But I get the "bad substitution" error

Ron Chan May 13, 2014

So you don't need to necessarily call build.sh. That was only an example file for Bamboo to call, which would contain your script. Since you're doing inline, then this might just be a syntax issue.

In your last example, after BUILD_USER is defined, try to reference that using $BUILD_USER

Xabier Davila May 14, 2014

Try creating a plan with this code in a script task:

if [ -n "${bamboo.jira.username}" ]; then
  
  BUILD_USER="${bamboo.jira.username}"
  
else
  
  BUILD_USER="${bamboo.ManualBuildTriggerReason.userName}"
  
fi

echo $BUILD_USER # Syntax here is not the issue

When you trigger it manually, you'll get this in the logs:

...
command	15-May-2014 08:25:33	Substituting variable: ${bamboo.ManualBuildTriggerReason.userName} with XabierDavila
...
error	15-May-2014 08:25:33	/opt/ds/bamboo-current/temp/DS-XAB-JOB1-32-ScriptBuildTask-163838233951804830.sh: line 2: JIRA Username: ${bamboo.jira.username}: bad substitution
...

That is *before* Bambo tries to run the script, so not a syntax error but an issue with Bamboo trying to do a substitution for an undefined variable.

If you trigger this job releasing a JIRA version, you'll get a similar error, but on line 4 this time, since ${bamboo.ManualBuildTriggerReason.userName} is not defined.

So, the problem is Bamboo doing the substitutions, not the Bash script itself. In fact, if you run this Bash script in your terminal:

#!/bin/sh

#bamboojirausername=John
#bambooManualBuildTriggerReasonuserName=Peter

if [ -n "${bamboojirausername}" ]; then
  BUILD_USER="${bamboojirausername}"
else
  BUILD_USER="${bambooManualBuildTriggerReasonuserName}"
fi

echo BUILD USER: ${BUILD_USER}

An test it like it is or removen the comments for 1 or the other variables at the top, you'll see it works fine. if [ -n var] handles undefined variables with no problems.

Ron Chan May 14, 2014

Alright, give this a try -

1. Set a Global Variable:
jira.username to notjira

2. Rewrite script:

if [ "${bamboo.jira.username}" == "notjira" ]; then

BUILD_USER="${bamboo.ManualBuildTriggerReason.userName}"

else

BUILD_USER="${bamboo.jira.username}"

fi

echo $BUILD_USER # Syntax here is not the issue

This should now work for both manual builds and from JIRA.

Xabier Davila May 18, 2014

This seems like a good solution, I'll test this and get back to you.

Thanks!!

Xabier Davila Jun 16, 2014

Had the chance to test this and works fine, so your last suggestion is the accepted answer.

For Atlassian, I have to say this is a quite dirty way to resolve this problem

Thanks Ron!!

0 votes

This fix apparently does not work anymore. We're running 5.6.2 currently. The new variable now seems to always override the build-specific key.

Xabier Davila Nov 14, 2014

Can you be a bit more specific with your issue? We are using this approach in 5.6.2 and it seems work fine for us

Yes, sorry about that, it was a bit brief. So I am trying to detect if the specific build was a scheduled build or not. It was scheduled, than this variable should exist: ${bamboo.ScheduledTriggerReason.scheduledDate} with a valid date in it. To prevent the substitution error, I've added a plan vaiable with the name "ScheduledTriggerReason.scheduledDate" and I've set it to the value "undef". Now for some reason the value always evaluates to "undef". If I look in the build metadata I see a "key" with the name "ScheduledTriggerReason.scheduledDate" and as value a timestamp. But I also see a variable with that same name and the value "undef". So I have a feeling the key cannot override the variable for some reason. I hope this makes more sense. Regards, Marko

Xabier Davila Nov 14, 2014

Are you running this as an inline script or in a file? bash, batch, PowerShell? I moved all my inline scripts to bash files. Bamboo variables are added as environment variables, so there's no way you can have 2 different values. Maybe that can fix your issue?

Hi thanks once more for the quick reply. I was running it in an inline script. I've tried running it inside bash files as well. But it seams the particular variable I'm looking for is never added to the environment. I'll have to come up with a different approach for my specific problem I guess.

0 votes
Mike Howells Atlassian Team Jan 23, 2015

If you run this as a script file rather than inline, you must use underscores instead of dots in the Bamboo variable names. If you do that then you will not get a substitution error because Bamboo does not do variable substitution on your script file, it sets environment variables instead. If you reference an undefined variable in your script you should just get a null value, so the if-statement should work. 

Suggest an answer

Log in or Sign up to answer
This widget could not be displayed.
This widget could not be displayed.
Community showcase
Posted in Statuspage

⭐️Would you recommend Statuspage? Leave a (honest!) review. ⭐️

Hi Community friends, We're working on sourcing more reviews on Capterra – a popular software review site –  to help teams like yours make more informed decisions when choosing an inc...

80 views 3 5
Join discussion

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you