Variables can be used to set static values that are used when building plans in Bamboo.

  • Global variables are defined across your entire Bamboo instance, and have the same (static) value for every plan that is built by Bamboo.
  • Plan variables are similar to global variables, but are defined for specific plans. Plan variables override global variables with the same name. You can also override a plan variable for a build, if you have triggered the build manually.
  • Build-specific variables are evaluated by Bamboo dynamically at build time. The source of a build-specific variable can either be a Bamboo property or one of the default plugins (assuming they have been enabled).
  • Deployment variables are a number of standard reserved variables that are available during deployment executions. 
  • System variables also apply across your entire Bamboo instance and inherit their values from system or environment variables of the same name.

You can generate variables of your own, using a similar format, however you cannot create a variable that is already in use by Bamboo. See Defining global variables and Defining plan variables.

How to use variables

Using variables

Variables can be used in all fields of a Task, with the exception of password variables. Variables can also be used with deployments.

${bamboo.variableName}

 

You can override a plan variable for a build, if you have triggered the build manually. For details, see  Triggering a plan build manually.

Defining variables

See Defining global variables for information on how to define your own global variables.

See  Defining plan variables  for information on how to define your own plan variables.

See  Defining deployment environment variables  for information on how to define your own plan variables.

On this page:

Related pages:

 

Build-specific variables

The following build-specific variables are available by default:

Build-specific variable

Description

bamboo.buildKey

The job key for the current job, in the form PROJECT-PLAN-JOB, e.g. BAM-MAIN-JOBX

bamboo.buildResultKeyThe result key when this job executes, in the form PROJECT-PLAN-JOB-BUILD e.g. BAM-BOO-JOB1-8, where '8' is the build number. For deployment projects this variable will not have the JOB component e.g. PROJ-TP-6.
bamboo.buildResultsUrlThe URL of the result in Bamboo once the job has finished executing.

bamboo.buildNumber

The Bamboo build number, e.g. 123

bamboo.buildPlanName

The Bamboo plan name e.g. Some Project name - Some plan name

bamboo.buildTimeStamp

The time when build was started in ISO 8601 format e.g. 2010-01-01T01:00:00.000+01:00

bamboo.buildForceCleanCheckout

Whether the "Force Clean Build" option was used, values:true/false

bamboo.build.working.directory

The working directory that the build is being executed on

bamboo.ManualBuildTriggerReason.userNameThe user who triggered the manual build
Generic repository variables 

bamboo.repository.revision.number

The revision number

bamboo.repository.branch.nameThe repository branch name (for Bamboo version 4.2 or later)

bamboo.repository.previous.revision.number

The previous revision number (might not exist if for example is initial build)

Subversion 

bamboo.custom.svn.revision.number

The revision number

bamboo.custom.svn.lastchange.revision.number

The last changed revision number

bamboo.custom.svn.username

User name used for repository authentication

bamboo.repository.svn.repositoryUrl

The repository url

CVS 

bamboo.custom.cvs.last.update.time

The last updated timestamp

bamboo.custom.cvs.last.update.time.label

The last updated timestamp to be used as a label for post build result labelling. The spaces in the cvs version string are replaced with '_'

Perforce 

bamboo.custom.p4.revision.number

The change set number

bamboo.custom.p4.username

User name used for repository authentication

bamboo.custom.p4.port

Port used for repository communication

bamboo.custom.p4.client

Client used for repository communication

Git 
bamboo.repository.git.branchThe branch
bamboo.repository.git.repositoryUrlThe repository url
Mercurial 

bamboo.repository.hg.repositoryUrl

The repository url

bamboo.repository.hg.branch

The branch

bamboo.repository.hg.username

User name used for repository authentication

  • System variables also apply across your entire Bamboo instance and inherit their values from system or environment variables of the same name.

Build dependent variables

The following build dependent variables are also available:

Build-specific variable

Description

bamboo.dependency.parent.#

Allows a child build to query the build key of the triggering parent build, where # represents the position in the build tree - 0 at the top, 1 the following, and so on. The ${bamboo.dependency.parent.0} variable can be viewed in the child plan's metadata tab.

dependency.parent.totalThe total # of parent builds.

Deployment variables

Bamboo manages a number of standard reserved variables that are available during deployment executions. 

Variables later in the following list override the previous ones in case of repeating names:

  • global variables
  • release variables as defined below
  • user variables defined at environment level
  • the autogenerated variables in the following table:
VariableDescription
bamboo.agentIDThe id of the agent that the deployment is executed on.
bamboo.agentWorkingDirectoryThe path to the working directory on the agent. This is not the same as the Bamboo working directory.
bamboo.build.working.directoryThe path to the working directory for Bamboo. This is used by both the build plan and the deployment project.
bamboo.deploy.environmentThe name of the environment that the release is to be deployed to.
bamboo.deploy.projectThe name of the deployment project.
bamboo.deploy.rollbackTrue if the release being deployed is older than the release being replaced.

bamboo.deploy.release

bamboo.deploy.version

The name of the release that is being deployed. Either .release or .version can be used - both return the name of the release being deployed.

bamboo.deploy.release.previous

bamboo.deploy.version.previous

The name of the release that is being replaced (if available). Either .release or .version can be used - both return the name of the release being replaced.
bamboo.resultsUrlThe URL to the screen in Bamboo that dispays build results.

You can generate variables of your own, using a similar format, however you cannot create a variable that is already in use by Bamboo. See Variables for deployment environments for more information on configuring your deployment environment variables.

Variables associated with releases

Bamboo makes the following types of variables available for deployment releases:

VariableDescription
bamboo.buildNumberThe build result from which the release is created.
bamboo.buildResultKeyThe key of the build result from which the release is created e.g. KUNG-FOO-JOB1-35
bamboo.planKeyThe key of the plan related to the release e.g. KUNG-FOO
bamboo.planNameThe name of the plan related to the release e.g. Kung - Foo
Repository 
bamboo.planRepository.<position>.branchNameThe name of the branch in the repository (depends on availability from the VCS used) e.g. default
bamboo.planRepository.<position>.nameThe name of of the repository, as shown in the repository for the plan e.g. Mercurial
bamboo.planRepository.<position>.revisionThe revision use to build this release. Format depends on the VCS used.
bamboo.planRepository.<position>.typeThe type of the repository, as defined by a repository plugin e.g. hg, svn, git

In the variable names in the table above, <position> is the repository in the plan's repository list. It can be ignored for the first repository on the list; that is planRepository.name is equivalent to planRepository.1.name.

Note that several of the variables in the above table are actually those associated with the build plan.

System variables

The usage format for all system variables is:

${system.<variable>}

For example, if you have a system variable MYPATH=C:\MyPath; you can use a Bamboo system variable system.MYPATH which will inherit the same value as the system variable.

(info) In older Bamboo versions using 'PATH' in the Environment Variables field (of a Script task) doesn't set the windows PATH variable, whereas using 'Path' sets Path and PATH in cmd shell.

Using variables in bash

Bamboo variables are exported as bash shell variables. All full stops (periods) are converted to underscores. For example, the variable bamboo.my.variable is $bamboo_my_variable in bash. This is related to File Script tasks (not Inline Script tasks).

JIRA application variables

Note that these variables can be accessed from a Bamboo build only when that build was triggered by releasing a version in a JIRA application.

JIRA variableDescription
${bamboo.jira.baseUrl}The URL of your JIRA application server.
${bamboo.jira.projectKey}The key of the triggering JIRA application project.
${bamboo.jira.projectName}The name of the triggering JIRA application project.
${bamboo.jira.version}The release version of the triggering JIRA application project.
${bamboo.jira.username}The username of the user who triggered the release build.

Examples

Maven examples

For example, you may want your Maven 2 version to be determined by Bamboo. In Maven 2 pom.xml you may have:

...
<groupId>com.atlassian.boo</groupId>
<artifactId>boo-test</artifactId>
<packaging>jar</packaging>
<version>1.1.${bambooBuildNumber}-SNAPSHOT</version>
...

You can then specify the following in the Goal field of your build plan:

clean package -DbambooBuildNumber=${bamboo.buildNumber}

When the command runs, Bamboo will replace the buildNumber with the actual number (e.g. 1102), which will be passed to the underlying Maven build to use. The command will then produce a jar that looks like this: boo-test-1.1.1102-SNAPSHOT.jar.

Ant examples

You can then specify the following in the Target field of your build plan:

-f build.xml -DbambooBuildNumber=${bamboo.buildNumber}

When the command runs, Bamboo will replace the buildNumber with the actual number (e.g. 1102), which will be passed to the underlying Ant build to use.

Specifying capabilities as variables

You can also specify a capability to be used in a similar way to a global variable.

The format of the capability should be as follows:

${bamboo.capability.<capability_key>}

For example,

  • Custom

    ${bamboo.capability.<capability_key>}

  • JDK

    ${bamboo.capability.system.jdk.<jdk_label>}

  • Builder

    ${bamboo.capability.system.builder.<builder_type>.<builder_label>}
e.g. ${bamboo.capability.system.builder.maven.Maven1}

  • Perforce

    ${bamboo.capability.system.p4Executable}

If you click on a capability, the specific capability key will be contained in the URL.

Please note, the space characters in the URL will be replaced with '+' characters. We recommend that you do not use capability labels with space characters, if you wish to use them as variables. A possible solution for space characters is to format them with '${}' symbols, however, this does not work in all cases.

Using capabilities

Global and Build-Specific Variables can be used in a specific fields of your build plan, as specified above. For capabilities,

  • System Capabilities are available to all of these fields, (i.e. global and build-specific).
  • Agent Capabilities (i.e. agent-specific and shared/server capabilities) are available only to the build-specific fields. (i.e. not available to Repository URL, CVS Root or Branch name.)

For example,

If you wanted to specify a system variable, but have it set to different values on each agent, do the following:

  1. Set the following as a system environment variable field on the Builder tab:

    ${bamboo.capability.thatsystemvariable}
  2. Specify the system environment variable as a custom capability on each of your agents, and set to the capability to the different values, as desired.

71 Comments

  1. Anonymous

    Mar 12, 2009

    Which variable should I use in order to find the current build directory?

    1. Anonymous

      Sept 24, 2011

      build directory - ${bamboo.projectBaseDir}

      I beleive this is from Bamboo, not a plugin.

      1. Anonymous

        Sept 24, 2011

        ${bamboo.projectBaseDir} doesn't seem to work on 2.6. I really need access to this variable though. Any other suggestions?

        1. AjayA

          Jul 09, 2010

          Folks,

          The {bamboo.projectBaseDir} variable is actually provided by the Bamboo pre/post build plugin:

          https://studio.plugins.atlassian.com/wiki/display/BPBC/Home

          Can you try installing this plugin?

          Cheers,
          Ajay.

          1. Robert Crosbie

            Aug 06, 2010

            For those who don't want to use the pre/post plugin, you can construct the build directory yourself.

            Create a custom capability on your agent(s) called build-dir.  For example:

            build-dir = C:\bamboo\xml-data\build-dir

            In your build plans you can use build-dir and buildKey to construct the project build directory:  For example:

            BUILDROOT=${bamboo.capability.build-dir}\${bamboo.buildKey}

            I still think Bamboo should provide a build directory variable by default though.

            1. Jared Morrow

              Nov 12, 2010

              Thanks for your comment, you are a life saver.   I tried using the variable buildWorkingDir that was listed elsewhere in the documentation with no luck, so I'm sure glad I got pointed to this page to see your comment.   I agree, I think there should be a default variable for working directory because I can see that being one of the most often used ones.

  2. Ulrich Kuhnhardt

    May 26, 2009

    The available variables are listed above. If you need other variables that represent bamboo parameters you can make them available via a plugin and persist them as custom.<my-variable>.

  3. Anonymous

    Oct 06, 2009

    Could I possibly get an nant example?  And is there anything special to be done in order to pass values back to Bamboo? 

  4. xavier lannoye

    Jan 28, 2010

    Hi

    I cannot access bamboo.custom.svn.revision.number varaible in my ant scripts.

    any suggestion welcome

    regards

    1. Alan Farkas

      Sept 24, 2011

      Are you passing the variable into your Ant script via the Bamboo Builder Panel?

      ex: svn.rev.num="${bamboo.custom.svn.revision.number}"

      In your ant script, you would reference this variable as such:

      "${env.svn.rev.num}"

  5. xavier lannoye

    Feb 09, 2010

    Hi

    I finally got it work using this way:

    in the builder tab, add the following parameter to the ant script (in "target" field)

    -Dmy.svn.revision=${bamboo.custom.svn.revision.number}

    then in my ant script I can reference those variable using

    $env.my.svn.revision

    et voilà

    regards

  6. user-4cc9e

    Aug 27, 2010

    Hi,

    Is-it possible to know the current user (how is executing the build) via the build-specific variables?

    I try to use the builder 'ant' to send an email on behalf of this user...

    Thanks,

    Bruno

  7. user-4cc9e

    Aug 27, 2010

    I did the following test: Send an email with substitution

    1. I have a plan with ant as builder.

    2. System Env Variables: -Dmy.bamboo.buildKey=${bamboo.buildKey} -Dmy.bamboo.buildNumber=${bamboo.buildNumber} -Dmy.bamboo.buildPlanName=${bamboo.buildPlanName} -Dmy.bamboo.buildTimeStamp=${bamboo.buildTimeStamp}

    3. build.xml 

    <project name="My Build" default="war" basedir=".">
    <target name="init">
        <property file="build.properties" />
        <property environment="env" />
    </target>
    
    <target name="request" depends="init" description="Send an email with bamboo vars">
	    <mail from="me@company.com" tolist="me@company.com" messagefile="Test.txt" subject="Test var bamboo"/> 
    </target>
</project>

    4. Test.txt

    Testing bamboo variables
bamboo.buildKey = ${env.my.bamboo.buildKey}
bamboo.buildNumber = ${env.my.bamboo.buildNumber}
bamboo.buildPlanName = ${env.my.bamboo.buildPlanName}
bamboo.buildTimeStamp = ${env.my.bamboo.buildTimeStamp}

    5. Result

    Testing bamboo variables
bamboo.buildKey = SDBX-SDBX
bamboo.buildNumber = 12
bamboo.buildPlanName = ${bamboo.buildPlanName}
bamboo.buildTimeStamp = ${bamboo.buildTimeStamp}

    7. Remarks

    Only buildKey and buildNumber are replaced by their value.

    Is-it a bug or one undocumented feature?

    We use bamboo version 2.4.2 build 1602

    1. user-4cc9e

      Aug 27, 2010

      (sad) bamboo.buildPlanName and bamboo.buildTimeStamp were not substitued in the version 2.4.2 (sad)

  8. Anonymous

    Sept 24, 2011

    In the bamboo  I am entering 

    cmcc_opts="D:/myworkspace" in the system variables. I am trying to fetch the variable from ant as ${system.cmcc_opts}

    But this is not returning me the correct result. Please suggest me some solution

  9. Anonymous

    Jan 19, 2011

    It would be nice if the table had a column about which Bamboo versions support the variable. It seems my current version does not have "custom.svn.lastchange.revision.number"...

  10. Anonymous

    Feb 16, 2011

    The buildKey now gives the composite plan-job name, not the plan name.

    e.g. "<myplan>-JOB1" by default

    It would be good if we could still get the actual plan name.

  11. Jared Morrow

    Mar 15, 2011

    If documentation isn't kept up-to-date and isn't correct for many versions of the tool, what is the point of the documentation?

    Is there a way to get JUST the plan name?   

    buildPlanName returns "Some Project name - Some plan name" and I need ONLY the plan name.

  12. Anonymous

    Jul 07, 2011

    Hi, What is the bamboo property represent current user logged in? I want to pass the property to ant script to let the ant script know who is running the script. thanks very much

    1. Chris Ferry

      Sept 20, 2011

      Can someone at Atlassian answer this?  I, as well, need to pass the "current user" value to an external script to notify users who has executed the build plan.

      1. PiotrA

        Sept 20, 2011

        Check this out: https://jira.atlassian.com/browse/BAM-7334 

        I reckon the feature you ask for will be (or is already?) implemented in the incoming Bamboo 3.3. I don't think it was possible in the older Bamboo versions to pass the "current user" value to the external scripts without some kind of external plugin...

  13. Jan Swaelens

    Jan 13, 2012

    I am looking to implement a link to the bamboo build page inside our application, to allow users to easily see what issues are fixed in the build and which features are added ...

    Is there a way to get to the actual bamboo root URL? With that I can manage to add the other path parts up to the relevant plan & build number.
    The only thing I can think of is define the root URL as a global variable, but wouldn't it be nice to have this built in?

    thanks 

  14. Aaron Evans

    Apr 13, 2012

    How can you access Bamboo plan or global variables from a shell script task?

  15. Anonymous

    Jul 12, 2012

    Hello,

    please give me a hint how to pass plan variable into Maven to be accessible inside a pom.xml.

    I tried this example syntax in my pom.xml

    <version>1.0.${bamboo.buildNumber}-SNAPSHOT</version>

    Then I ran build within Bamboo and get the following Maven warning

    11-Jul-2012 21:10:31
    [WARNING] Some problems were encountered while building the effective model for com.abc.def.UI-tests:UI-tests:jar:1.0.${bamboo.buildNumber}-SNAPSHOT
    11-Jul-2012 21:10:31
    [WARNING] 'version' contains an expression but should be a constant. @ line 7, column 12
    11-Jul-2012 21:10:31
    [WARNING]
    11-Jul-2012 21:10:31
    [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
    11-Jul-2012 21:10:31
    [WARNING]
    11-Jul-2012 21:10:31
    [WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
    11-Jul-2012 21:10:31
    [WARNING]

    Actually I defined plan variable "InstanceName" and want to pass its' value into my Java programm over System.properties.

    This trick is "almost" working except the fact I still unable to access the "InstanceName" variable value inside my pom.xml.

    The "trick" was picked up from the Parameterized web tests with Maven and Selenium article

    When I use hardcoded value in my pom.xml it is successfully passed into my Java program and become accessible over System.getProperties

    11-Jul-2012 21:10:37 lg.instance.name=stage

    I use the following syntax in my pom.xml

     
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.12</version>
            <configuration>
             <systemProperties>
                 <property>
                   <name>lg.instance.name</name>
    <!-- ******************************************** -->        
    <!-- DEFINE instance name (testing or stage) here -->        
    <!--           <value>stage</value>               -->
    <!--           <value>testing</value>             -->
    <!-- ******************************************** -->        
                   <value>stage</value>
                 </property>
              </systemProperties>

     

    If I using my plan variable reference, then the value is always empty.

    I tried to reference this variable inside pom.xml for several syntax, but none of attempts were succeeded.

    ${bamboo.InstanceName} ${env.InstanceName} ${env.bamboo.InstanceName} ${system.bamboo_InstanceName}

    The only result I see within Bamboo build log file is that my variables are somehow mentioned in some note.

    11-Jul-2012 21:10:31

    Beginning to execute external process for build 'LG UI tests - LG UI tests - specific - LG Web UI tests'
    ... running command line: C:\maven\maven-3.0.4\bin\mvn.bat -Djava.io.tmpdir=C:\DOCUME~1\Tester\LOCALS~1\Temp\1\LGUI2-SPEC-JOB1 -f pom_specific.xml test
    ... in : C:\Documents and Settings\Tester\bamboo-agent-home\xml-data\build-dir\LGUI2-SPEC-JOB1
    ... using extra environment variables: MAVEN2_HOME=C:\maven\maven-3.0.4 JAVA_HOME=C:\Program Files\Java\jdk1.6.0_25 bamboo_ANT_HOME=C:\ANT M2_HOME=C:\maven\maven-3.0.4 bamboo_bar=bar bamboo_InstanceName=stage bamboo_foo=foo PATH=C:\Program Files\Java\jdk1.6.0_25\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Java\jdk1.6.0\bin;c:\maven\bin;C:\ANT\bin;C:\android_sdk\platform-tools;C:\sikuli-x\libs;C:\Program Files\Java\jre6\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Java\jdk1.6.0_25\bin;c:\maven\maven-3.0.4\bin;C:\ANT\bin;C:\android_sdk\platform-tools;C:\sikuli-x\libs

     

    I guess the problem is I using wrong reference to a PlanVariable.

    Could you give me a hint what is the right way to reference plan variable in Maven pom.xml?

     

    1. EddieW

      Sept 06, 2012

      The value inside your pom can be anything (staring with env., meaning use a mathcing java environment property), what is important is that you specify a mathcing name as an argument.


      inside pom.xml (note the env. prefix

      ${env.thiswillbereplaced}

       

      as an argument (note the absence of env. prefix 
      -Dthiswillbereplaced=${bamboo.definedBambooVariable}

  16. Anonymous

    Aug 30, 2012

    Can I set plan variables in a script task?

    1. EddieW

      Sept 06, 2012

      Yes, see the table above for a list of places variables can be used. specificvariables-variablefieldsUsingvariables

    2. ArmenA

      Sept 06, 2012

      Yes, you might want to have a look at this page.

       

  17. Anonymous

    Sept 19, 2012

    Is it possible to override variables at runtime, inside the shell script.
    I need to set custom.svn.revision.number  in the beginning of the build and let other stages/jobs/tasks use the same revision number.

    I know it is possible to do that when you run customized build, but I want to do that automatically as my build is triggered every half an hour if changes are detected in subversion.

    Thanks,
    Aleksandar 

    1. James Dumay

      Sept 20, 2012

      All Jobs within the same plan will use the same revision number. Using custom.svn.revision.number to set a specific revision does not work - please watch and vote for this ticket  BAM-1640 - Getting issue details... STATUS  

  18. Anonymous

    Sept 27, 2012

    Is there a possibility to pass forms, errors or other requests for user-interaction back to the bamboo-ui, while executing a script?

  19. Anonymous

    Oct 22, 2012

    I have noticed that the documentation above does not mention the changes that occur if you try to use a variable in a script build task. Exert from build log:

    Beginning to execute external process for build 'A New Project - A New Plan - Default Job'
    ... running command line:
    /bin/sh
    bamboo/plan.sh
    ... in: /usr/local/Bamboo/xml-data/build-dir/ANP-ANP-JOB1
    ... using extra environment variables:
    bamboo_PlanVar=APlanVariable

    So the usage format changes if you are using a script. Could we get an example to show this please.

    1. PiotrA

      Oct 22, 2012

      Hello,

      AFAIK in script task you use the same format for variable substitution, i.e. ${bamboo.PlanVar}. Or are you asking about the extra environment variables that Bamboo injects into tasks, that can be used by underlying processes? Like the bamboo_PlanVar from your example?

  20. Pavel Kudrys

    Dec 15, 2012

    Hi folks,

    Could you please point me to a correct direction, how to pass the build working directory from one build to another or for example to a command, started after the builds?

    I mean, let's say I have two builds in my plan and I want to use the build working directory from the first build in the second build or the command started at the end of both builds?

    And one more question, is there a variable returning the full path of compiled program (from build)?  

    Thank you in advance!

  21. James Dumay

    Dec 17, 2012

    I mean, let's say I have two builds in my plan and I want to use the build working directory from the first build in the second build or the command started at the end of both builds?

    You can't do it like that - Jobs within the same Plan will use completely different working directories. BTW if both Jobs are configured to checkout the same repository they will checkout at exactly the same revision.

    If you want to pass files between Stages and Jobs, see Configuring Artifact Sharing between Jobs (Note that its not recommend that you pass whole working directories this way)

    1. Pavel Kudrys

      Dec 17, 2012

      Hi James,

      Thank you for the reply. Sorry for a confusion. I don't want to actually use the working directory of the first build in the second dir. What I want is to pass the working dir/bin dir path from the first build to the second build and the command task started at the end of both builds (to use it as a command argument). I'm not sure the artifacts are the way to do this, but I will explore it (wink) Thanks anyway!

      Pavel

      1. James Dumay

        Dec 18, 2012

        I'm not sure the artifacts are the way to do this

        Passing the artifacts you need to the next Stage is probably the way you need todo it. If you have any further questions, let me know (smile)

  22. Pavel Kudrys

    Dec 18, 2012

    Hi James,

    Thank you for the reply. OK, I will check the documentation about artifacts and eventually ask a question or two (wink)

  23. Anonymous

    Jan 18, 2013

    Help needed. I want to assign a value to a Bamboo variable from inside a bash script so that I can then pass that value to other tasks, but I can't because bash doesn't allow periods to be part of a variable name and Bamboo variables always contain periods.

    1. ArmenA

      Jan 19, 2013

      Bamboo currently doesn't support assigning variable values from a script task (no variable value can be manually changed after running the build).

  24. Anonymous

    Feb 08, 2013

    trying to... troubleshoot... this documentation error

  25. Keith Miller

    Feb 28, 2013

    For the record, you can get the Git repository URL as well, just use bamboo.repository.git.repositoryUrl. For example:

    In Ant, use -Dtest.value=${bamboo.repository.git.repositoryUrl}, and in your output you'll see:

    Substituting variable: ${bamboo.repository.git.repositoryUrl} with git@github-internal.mycompany.com:internal-test/code.git

    You should add this to the documentation. 

  26. Brian Jones

    Mar 06, 2013

    It does not appear that any variables are available on Windows in the shell when executing a Script task. The only way I've been able to access bamboo variables is to code them using the ${variable} syntax in an inline script or as a command argument. They are not propagated to the windows command line shell in any way. The section on using variables in bash does not appear to apply to Windows git bash. I suspect this is only for Linux? The documentation is unclear on what context this applies to.

    1. James Dumay [Atlassian]

      Mar 12, 2013

      Hi Brian,

      This should work on Windows too. What do you get when you run set from a Bamboo Script task? If you can't see the variables from the output of that command please get in touch with our support team.

      On Windows, your variable as an environment variable looks like:

      %BAMBOO_YOUR_VARIABLE% where the bamboo variables name was bamboo.your.variable (replacing all spaces with _ and capitalising all characters).

      1. Anonymous

        Mar 12, 2013

        I had tried displaying the environment by executing 'set' in the script. No bamboo variables showed up. I'll open a support ticket. Thanks. --Brian

      2. Brian Jones

        Mar 19, 2013

        James,

        Would you mind chiming in on my issue BSP-9525? There appears to be quite a lot of confusion regarding what behavior Bamboo should exhibit with respect to variables. Thanks!

        Brian

        1. Vasanth Manikumar

          May 21, 2013

          That seems to be incorrect information.  In a bash script this it what worked for me:

          variable name = git.release.branch

          With the above plan/global variable name, this is what works in bash:

          echo $bamboo_git_release_branch

          No caps and underscores for periods!  Hope this saves someone else all the confusion, and hopefully Atlassian will update the docs page above.

  27. Kenny MacLeod

    Apr 15, 2013

    The "bamboo.buildPlanName" variable actually seems to resolve to the combination of the plan name and the job name, i.e. "PLANNAME - JOBNAME", rather than just "PLANNAME". The docs above say it should just be the PLANNAME.

  28. Tyler Mace

    May 10, 2013

    Documentation says that those variables are also available in "bash." Why just bash? Are they also available to python, perl, cshell, batch files, binary-executables, also in this way?

     

    1. Kelly Schoenhofen

      Jun 25, 2013

      I think their documentation is abit misleading; inline scripts or the default script builder uses /bin/sh to execute scripts; not bash. So essentially, these variables are available "via the sh shell", unless you use a custom builder (like create your own that runs /bin/bash). Does that make more sense/is that more accurate?

  29. Anonymous

    Jul 25, 2013

    Can anybody tell me what '-JOB1' in the job-names means?

    1. ArmenA

      Jul 26, 2013

      JOB1 is the key of the job. Let's say if you click on a job from Bamboo UI, in the URL (in your web browser) you will see something like: PROJ1-PLAN1-JOB1, which is the full key of your job. PROJ1 is the key of the project, PLAN1 is the key of the plan, and the JOB1 is the key of the job. Those key names are identified when creating the Project, Plan and the Job.

  30. Sylvain Laurent

    Aug 23, 2013

    Is it possible to override deployment variables when deploying to an environment ? more specifically, I'd like to require a password when deploying with Bamboo 5.

  31. Ron Chan

    Aug 28, 2013

    Is there a way to create a custom value (i.e. created from a script) and pass that back to Bamboo to use?

    1. ArmenA

      Aug 30, 2013

      No, Bamboo substitutes variables and then starts the plan tasks, so there no way to pass any variables or change the values of existing ones.

    2. Ron Chan

      Feb 05, 2014

      I am still waiting for such a feature to exist and very disappointed that it does not.

      However, I'm definitely not going to hold my breath waiting for it to happen.  

       

       

      1. EddieW

        Feb 05, 2014

        Job level variables can be created and substituted within the scope of a single job.  Plan variables are locked at the start as ArmenA points out.

        If you want to use job level variables from a shell task, I would suggest writing to a .properties file, and then using the Inject Variables Plugin to convert the file to variables (only available to subsequent tasks in that job!).

         

        Some plugins can also update Planlevel variables, but the change is not reflected until the next run.

  32. Kevin Dixon

    Oct 10, 2013

    Can you please put a guide showing how all of the different capabilities map out to variables?

    Currently I am using trial and error, and it is terrible!!

    I finally figured out:

    ${bamboo.capability.system.builder.command.<CommandName>}

    but there are so many more? How do you reference a custom capability?

    1. ArmenA

      Oct 17, 2013

      Hi Kevin,

      As you can see on the current page, you can access your custom capabilities this way:

      ${bamboo.capability.your_capability_key}

      where the "your_capability_key" is the custom capability which value you are trying to get.

      1. Kevin Dixon

        Oct 17, 2013

        Thank you. I had discovered this since then.

        My actual problem is that I had spaces in my capability keys. I tried to replace them with "+" as the documentation suggested, but that did not work at all. I had to re-do all my capabilities to use underscore, or no spaces.

  33. Matthew Bastress

    Nov 07, 2013

    There is a typo above in the line:

    <version>1.1.${bamboo.BuildNumber}-SNAPSHOT</version>

    It should be "${bambooBuildNumber}". It is referencing a Maven property specified as:

    clean package -DbambooBuildNumber=${bamboo.buildNumber}

  34. NathanA

    Nov 07, 2013

    Thanks Matthew, I have fixed it up now.

  35. Ron Chan

    Nov 15, 2013

    I have ran into a bug with Bamboo variables for deployments  BAM-13730 - Getting issue details... STATUS

    Can someone tell me if and when this can get fixed?  It's preventing us from utilizing Bamboo deployments.

     

  36. user-055e6

    Nov 21, 2013

    Is there a way to get a hold of the current bamboo username and password as variables for deployments?

    1. ArmenA

      Nov 22, 2013

      Not really. Feel free to raise a new feature request here - https://jira.atlassian.com.

  37. Mehul Sanghvi

    Nov 25, 2013

    I am trying to use bamboo.planKey and pass it to maven as part of the one of its "Goal" options.  

    -sfoo.bar.settings=${bamboo.planKey}-JOB1/settings.xml
-Dfoo.bar.build.num=${bamboo.buildNumber}
-Dhost.os=${system.os.name}

    bamboo.buildNumber and system.os.name get resolved correctly.  planKey is left as is i.e. in the logs it shows up as ${bamboo.planKey} rather than having a value substituted for it.  In this case I would expect to see KUNG-FU being substituted for bamboo.planKey, but that does not happen.

     

    Any thoughts/suggestions/workarounds ?

     

    1. ArmenA

      Nov 25, 2013

      Hi Mehul,

      Which version of Bamboo are you using? I just tried the same configuration with Bamboo 5.2.2 and it was correctly substituted in my Maven 3 task:

      Substituting variable: ${bamboo.planKey} with PROJ-PLAN

      Is it an option for you to use the bamboo.buildKey variable instead of bamboo.planKey? If you need more assistance, please raise a new ticket on https://support.atlassian.com, and we will go from there.

      Armen

      1. Mehul Sanghvi

        Nov 25, 2013

        Hi Armen,

              We are using the following version:

         

                     4.4.5 build 3507 - 27 Mar 13

         

               I can not use the bamboo.buildKey as that includes the JOB in it.  I need to refer to the PROJ-PLAN.  Is there some other way besides bamboo.planKey that I can get that information ? 

        1. ArmenA

          Nov 26, 2013

          I don't think there is any elegant workaround if the bamboo.planKey variable doesn't get substituted. You might want to define a plan variable with the mentioned value and use that variable in your Maven task.

  38. Odin Odin

    Jan 03, 2014

    Is there a way to list all available Bamboo variables from a script task? I'm trying to figure out the plan key of the immediate parent when I do not know the number of parents (i.e i could have used the number of parents to figure out the correct X in bamboo.dependencies.parent.X if only Bamboo would support redefining variables). 

  39. Stephen Kestle

    Jan 15, 2014

    `bamboo.buildResultsUrl` should have an example - I presume http://bamboo/browse/BAM-BOO-JOB1-8

    Is there a variable for http://bamboo/browse/BAM-BOO-8?

    Or do I have to configure "http://bamboo/browse/${bamboo.buildPlanName}-${bamboo.buildNumber}" myself? My apologies - there is no variable that I can see that provides the plan key