Skip to end of metadata
Go to start of metadata

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.


You can override a plan variable for a build, if you have triggered the build manually. For details, 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 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.


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


The Bamboo build number, e.g. 123


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


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


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

The working directory that the build is being executed on

bamboo.ManualBuildTriggerReason.userNameThe user who triggered the manual build
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 if for example is initial build)



The revision number


The last changed revision number


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.repository.git.branchThe branch
bamboo.repository.git.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.

Build dependent variables

The following build dependent 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.

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

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.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 is equivalent to

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:

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

  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.


  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 Configuring Artifact Sharing between Jobs (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.

  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 Open

    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