Skip to end of metadata
Go to start of metadata

Variables can be used to make values available when building plans in Bamboo.

  • 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 it is enabled).
  • Deployment variables are available when deploying a project. 
  • System variables also apply across your entire Bamboo instance and inherit their values from system or environment variables of the same name.
  • Global variables are defined across your entire Bamboo instance, and have the same (static) value for every plan that is built by Bamboo. See Defining global variables.
  • 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 trigger the build manually. See Defining plan variables.

Using variables

Variables can be used in all fields of a task or deployment, with the exception of password fields. Use the following format when referencing a variable:

You can override a plan variable for a build, if you trigger the build manually. See Triggering a plan build manually.

(warning) You cannot reference a variable from another variable in Bamboo, i.e. "double de-referencing". See this knowledge base article for more information.

Defining custom variables

You can define your own custom variables, using a similar format to that above, however you cannot create a variable name that is already in use by Bamboo.

For information on how to define your own variables in Bamboo, see:

Build-specific variables

The following build-specific variables are available by default:

Build-specific variable



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

bamboo.planKeyThe key of the current plan, in the form PROJECT-PLAN, e.g. BAM-MAIN
bamboo.shortPlanKeyThe short key of the current plan (without project part), e.g. MAIN
bamboo.shortJobKeyThe short key of the current job (without project and plan parts), e.g. JOBX


The 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.




The URL of the result in Bamboo once the job has finished executing.


The Bamboo build number, e.g. 123


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

bamboo.planNameThe current plan's name e.g. Some project name - Some plan name
bamboo.shortPlanNameThe current plan's name without project part, e.g. Some plan name
bamboo.shortJobNameThe current job's name without project and plan parts, e.g. Some job name


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

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.

The working directory that the build is being executed on.

bamboo.ManualBuildTriggerReason.userNameThe user who triggered the manual build.
Generic repository variables 
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>.previousRevisionThe previous revision number (this might not exist, for example for the initial build).
bamboo.planRepository.<position>.typeThe type of the repository, as defined by a repository plugin e.g. hg, svn, git


User name, used for repository authentication.


The repository URL.



The last updated timestamp.


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 '_'.



The change set number.


User name, used for repository authentication.


Port used for repository communication.


Client used for repository communication.

bamboo.planRepository.<position>.branchThe branch
bamboo.planRepository.<position>.repositoryUrlThe repository URL


The repository URL


The branch


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.
  • In the variable names from the table above, <position> is an optional parameter that specifies the position of the repository in the plan's repository list. If omitted, the first repository in the list is used.
  • Third-party repository plugins can expose their own variables.

Build dependency variables

The following build dependency variables are also available:

Build-specific variable



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.

bamboo.dependency.parent.totalThe total # of parent builds.

Deployment variables

Bamboo manages a number of standard reserved variables that are available when deploying a project. 

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:
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. 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.



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.



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 Defining deployment environment variables for more information.

Releases variables

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

  • Snapshots of values for global variables.
  • Snapshots of values for plan variables.
  • Snapshots of values of repository variables.
  • The autogenerated release variables in the following table:
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
bamboo.shortPlanKeyThe short key of the plan related to the release (without project part), e.g. MAIN
bamboo.shortPlanNameThe plan's name without project part, e.g. Some plan 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:

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 is $bamboo_my_variable in bash. This is related to File Script tasks (not Inline Script tasks).

JIRA variables

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

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


Maven examples

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

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:

For example,

  • Custom

  • JDK

  • Builder

  • Perforce

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 URLCVS 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:

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

  • 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.

Deprecated variables

The following variables are deprecated and are subject for removal in future Bamboo releases:

Generic repository variables 


The revision number.

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


The previous revision number (might not exist, for example for the initial build).



The revision number.


The last changed revision number.


User name used for repository authentication.


The repository URL.


The revision number.


The last-changed revision number.



The last updated timestamp.


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 '_'.



The change set number.


User name used for repository authentication.


Port used for repository communication.


Client used for repository communication.

bamboo.repository.git.branchThe branch.
bamboo.repository.git.repositoryUrlThe repository URL.


The repository URL.


The branch.


User name, used for repository authentication.


  1. Anonymous

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

    1. Anonymous

      build directory - ${bamboo.projectBaseDir}

      I beleive this is from Bamboo, not a plugin.

      1. Anonymous

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

        1. Folks,

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

          Can you try installing this plugin?


          1. 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:

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

            1. 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. 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

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

  4. Hi

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

    any suggestion welcome


    1. 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:


  5. Hi

    I finally got it work using this way:

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

    then in my ant script I can reference those variable using

    et voilà


  6. 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...



  7. 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

    4. Test.txt

    5. Result

    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. (sad) bamboo.buildPlanName and bamboo.buildTimeStamp were not substitued in the version 2.4.2 (sad)

  8. Anonymous

    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

    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

    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. 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

    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. 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. Check this out: 

        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. 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?


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

  15. Anonymous


    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


    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${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
    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
    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

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

    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

    I use the following syntax in my pom.xml

    <!-- ******************************************** -->        
    <!-- DEFINE instance name (testing or stage) here -->        
    <!--           <value>stage</value>               -->
    <!--           <value>testing</value>             -->
    <!-- ******************************************** -->        


    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\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. 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



      as an argument (note the absence of env. prefix 
  16. Anonymous

    Can I set plan variables in a script task?

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

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


  17. Anonymous

    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.


    1. 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 - Bamboo should be able to build to specific revision numbers Resolved  

  18. Anonymous

    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

    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:
    ... in: /usr/local/Bamboo/xml-data/build-dir/ANP-ANP-JOB1
    ... using extra environment variables:

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

    1. 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. 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. 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 Sharing artifacts (Note that its not recommend that you pass whole working directories this way)

    1. 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!


      1. 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. 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

    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. 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

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

  25. 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

    You should add this to the documentation. 

  26. 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. 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

        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. 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!


        1. 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.

          1. For Bamboo 5.8.1, I found that ${bamboo.planRepository.branchName} represents the branch name (at least with Git).   This of course doesn't match the above documented names.  There is no <position> in the variable name at all.  (shrug).  

            1. "In the variable names from the table above, <position> is an optional parameter that specifies the position of the repository in the plan's repository list. If omitted, the first repository in the list is used"

  27. 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. 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. 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

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

    1. 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. 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. Is there a way to create a custom value (i.e. created from a script) and pass that back to Bamboo to use?

    1. 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. 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. Job level variables can be created and substituted within the scope of a single job.  Plan variables are locked at the start as Armen Khachatryan [Atlassian] 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. 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:


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

    1. Hi Kevin,

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

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

      1. 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. There is a typo above in the line:


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

    clean package -DbambooBuildNumber=${bamboo.buildNumber}
  34. Thanks Matthew, I have fixed it up now.

  35. I have ran into a bug with Bamboo variables for deployments  BAM-13730 - Variable values are not getting substituted for deployments when triggered from JIRA Resolved

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


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

    1. Not really. Feel free to raise a new feature request here -

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

    bamboo.buildNumber and 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. 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:

      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, and we will go from there.


      1. 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. 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. 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. `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

  40. It seems like bamboo.agentID should be bamboo.agentId as of bamboo version 5.5.

  41. I want to declare list of ip address of the servers where bamboo can deploy the codebase. In the bamboo deployment variables, I've added (space-delimited ip address) servers variable and tried accessing it in the deployment task wherein it will loop through each of the ip addresses and do the deployment. It doesn't work. Is there any way that I can declare an array of values in the environment variables?

    Environment Variable
  42. How can i write ${bamboo.jira.version} variable in some global variable on running build from jira to use it later in builds and deployments?

    1. It is added automatically when using 'Build & release' feature in JIRA.

      1. Yes, but i want to use it in deploy later, or in another builds running not from jira.

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

        How can i set global variable not manualy? for example i need bamboo.globalJIRAVersion = ${bamboo.jira.version}

  43. Maybe someone knows how can i overwrite global variable by temporary value? for example in special siations bamboo provides special variables, i want to save it to global one, for example i need bamboo.globalJIRAVersion = ${bamboo.jira.version}, i tried to set in plan variables this value ${bamboo.jira.version} to global variable but it doesn't work. Thanks

  44. Is there any way to get only the first few chars of git revision? The variable ${bamboo.repository.revision.number} works great except it's too long (41 characters).

  45. Hi, 

    I'm using tagging repository approach for deploying my code. 

    My problem is buildKey which is a element of my tag build: build/${bamboo.buildKey}-${bamboo.buildNumber}

    When i'm using a alternative branch of my repo it makes a key like D1D (for main branch) and D1D0 D1D1 D1D2 for subbranches.

    When subbranch is deleted and another one is created it goes back to D1D0, furthermore buildNumber is reseted too - so my tags already exists in repository when i'm approaching in this solution. Is there any posibilitty to extract fully uniqe ID which I could extract in deployment plan ?


    1. In Bamboo 5.5.1 branch build keys are no longer reused

  46. Do we have a variable which can give us the result of build plan just as failed or passed?

  47. Is there a deploy variable for the user who initiated the deploy? I could not see one in the documentation above.