Bamboo variables

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

Description

bamboo.buildKey

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

bamboo.planKey The key of the current plan, in the form PROJECT-PLAN, e.g. BAM-MAIN
bamboo.shortPlanKey The short key of the current plan (without project part), e.g. MAIN
bamboo.shortJobKey The short key of the current job (without project and plan parts), e.g. JOBX

bamboo.buildResultKey

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.

bamboo.buildResultsUrl

or

bamboo.resultsUrl

The 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 job name e.g. Some Project name - Some plan name - Some job name

bamboo.planName The current plan's name e.g. Some project name - Some plan name
bamboo.shortPlanName The current plan's name without project part, e.g. Some plan name
bamboo.shortJobName The current job's name without project and plan parts, e.g. Some job name

bamboo.buildTimeStamp

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

bamboo.agentId The ID of the agent that the deployment is executed on.
bamboo.agentWorkingDirectory The path to the working directory on the agent. This is not the same as the Bamboo working directory.

bamboo.build.working.directory

The working directory that the build is being executed on.

bamboo.ManualBuildTriggerReason.userName The user who triggered the manual build.
Generic repository variables  
bamboo.planRepository.<position>.branchName The name of the branch in the repository (depends on availability from the VCS used) e.g. default
bamboo.planRepository.<position>.name The name of of the repository, as shown in the repository for the plan e.g. Mercurial
bamboo.planRepository.<position>.revision The revision use to build this release. Format depends on the VCS used.
bamboo.planRepository.<position>.previousRevision The previous revision number (this might not exist, for example for the initial build).
bamboo.planRepository.<position>.type The type of the repository, as defined by a repository plugin e.g. hg, svn, git
Subversion  

bamboo.planRepository.<position>.username

User name, used for repository authentication.

bamboo.planRepository.<position>.repositoryUrl

The repository URL.

CVS  

bamboo.planRepository.<position>.last.update.time

The last updated timestamp.

bamboo.planRepository.<position>.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.planRepository.<position>.revision.number

The change set number.

bamboo.planRepository.<position>.username

User name, used for repository authentication.

bamboo.planRepository.<position>.port

Port used for repository communication.

bamboo.planRepository.<position>.client

Client used for repository communication.

Git  
bamboo.planRepository.<position>.branch The branch
bamboo.planRepository.<position>.repositoryUrl The repository URL
Mercurial  

bamboo.planRepository.<position>.repositoryUrl

The repository URL

bamboo.planRepository.<position>.branch

The branch

bamboo.planRepository.<position>.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.
  • 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

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.total The 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:
Variable Description
bamboo.agentId The id of the agent that the deployment is executed on.
bamboo.agentWorkingDirectory The path to the working directory on the agent. This is not the same as the Bamboo working directory.
bamboo.build.working.directory The path to the working directory for Bamboo. This is used by both the build plan and the deployment project.
bamboo.deploy.environment The name of the environment that the release is to be deployed to.
bamboo.deploy.project The name of the deployment project.
bamboo.deploy.rollback True 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.resultsUrl The 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:
Variable Description
bamboo.buildNumber The build result from which the release is created.
bamboo.buildResultKey The key of the build result from which the release is created e.g. KUNG-FOO-JOB1-35
bamboo.planKey The key of the plan related to the release e.g. KUNG-FOO
bamboo.planName The name of the plan related to the release e.g. Kung - Foo
bamboo.shortPlanKey The short key of the plan related to the release (without project part), e.g. MAIN
bamboo.shortPlanName The 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 bamboo.my.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 variable Description
${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.

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:

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  

bamboo.repository.revision.number

The revision number.

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

bamboo.repository.previous.revision.number

The previous revision number (might not exist, for example for the 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.

bamboo.planRepository.<position>.revision.number

The revision number.

bamboo.planRepository.<position>.lastchange.revision.number

The last-changed revision number.

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

Was this helpful?

Thanks for your feedback!

85 Archived comments

  1. User avatar

    Anonymous

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

    12 Mar 2009
    1. User avatar

      Anonymous

      build directory - ${bamboo.projectBaseDir}

      I beleive this is from Bamboo, not a plugin.

      11 Jun 2009
      1. User avatar

        Anonymous

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

        06 Jul 2010
        1. User avatar

          Ajay Sridhar [Atlassian]

          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.

          09 Jul 2010
          1. User avatar

            Robert Crosbie

            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.

            06 Aug 2010
            1. User avatar

              Jared Morrow

              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.

              12 Nov 2010
  2. User avatar

    Ulrich Kuhnhardt

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

    26 May 2009
  3. User avatar

    Anonymous

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

    06 Oct 2009
  4. User avatar

    xavier lannoye

    Hi

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

    any suggestion welcome

    regards

    28 Jan 2010
    1. User avatar

      Alan Farkas

      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}"

      09 Feb 2010
  5. User avatar

    xavier lannoye

    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à

    regards

    09 Feb 2010
  6. User avatar

    Bruno BLAISE

    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

    27 Aug 2010
  7. User avatar

    Bruno BLAISE

    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

    27 Aug 2010
    1. User avatar

      Bruno BLAISE

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

      27 Aug 2010
  8. User avatar

    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

    21 Sep 2010
  9. User avatar

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

    19 Jan 2011
  10. User avatar

    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.

    16 Feb 2011
  11. User avatar

    Jared Morrow

    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.

    15 Mar 2011
  12. User avatar

    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

    07 Jul 2011
    1. User avatar

      Chris Ferry

      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.

      20 Sep 2011
      1. User avatar

        Piotr Stefan Stefaniak [Atlassian]

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

        20 Sep 2011
  13. User avatar

    Jan Swaelens

    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 

    13 Jan 2012
  14. User avatar

    Aaron Evans

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

    13 Apr 2012
  15. User avatar

    Anonymous

    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?

     

    12 Jul 2012
    1. User avatar

      Eddie Webb

      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}
      06 Sep 2012
  16. User avatar

    Anonymous

    Can I set plan variables in a script task?

    30 Aug 2012
    1. User avatar

      Eddie Webb

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

      06 Sep 2012
    1. User avatar

      Armen Khachatryan [Atlassian]

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

       

      06 Sep 2012
  17. User avatar

    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.

    Thanks,
    Aleksandar 

    19 Sep 2012
    1. User avatar

      James Dumay [Atlassian]

      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  

      20 Sep 2012
  18. User avatar

    Anonymous

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

    27 Sep 2012
  19. User avatar

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

    22 Oct 2012
    1. User avatar

      Piotr Stefan Stefaniak [Atlassian]

      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?

      22 Oct 2012
  20. User avatar

    Pavel Kudrys

    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!

    15 Dec 2012
  21. User avatar

    James Dumay [Atlassian]

    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)

    17 Dec 2012
    1. User avatar

      Pavel Kudrys

      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

      17 Dec 2012
      1. User avatar

        James Dumay [Atlassian]

        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)

        18 Dec 2012
  22. User avatar

    Pavel Kudrys

    Hi James,

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

    18 Dec 2012
  23. User avatar

    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.

    18 Jan 2013
    1. User avatar

      Armen Khachatryan [Atlassian]

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

      19 Jan 2013
  24. User avatar

    Anonymous

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

    08 Feb 2013
  25. User avatar

    Keith Miller

    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. 

    28 Feb 2013
  26. User avatar

    Brian Jones

    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.

    06 Mar 2013
    1. User avatar

      James Dumay [Atlassian]

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

      12 Mar 2013
      1. User avatar

        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

        12 Mar 2013
      1. User avatar

        Brian Jones

        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

        19 Mar 2013
        1. User avatar

          Vasanth Manikumar

          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.

          21 May 2013
          1. User avatar

            Steve Woodruff

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

            25 Jun 2015
            1. User avatar

              Marcin Gardias [Atlassian]

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

              29 Jun 2015
  27. User avatar

    Kenny MacLeod

    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.

    15 Apr 2013
  28. User avatar

    Tyler Mace

    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?

     

    10 May 2013
    1. User avatar

      Kelly Schoenhofen

      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?

      25 Jun 2013
  29. User avatar

    Anonymous

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

    25 Jul 2013
    1. User avatar

      Armen Khachatryan [Atlassian]

      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.

      26 Jul 2013
  30. User avatar

    Sylvain Laurent

    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.

    23 Aug 2013
  31. User avatar

    Ron Chan

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

    28 Aug 2013
    1. User avatar

      Armen Khachatryan [Atlassian]

      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.

      30 Aug 2013
    1. User avatar

      Ron Chan

      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.  

       

       

      05 Feb 2014
      1. User avatar

        Eddie Webb

        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.

        05 Feb 2014
  32. User avatar

    Kevin Dixon

    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?

    10 Oct 2013
    1. User avatar

      Armen Khachatryan [Atlassian]

      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.

      17 Oct 2013
      1. User avatar

        Kevin Dixon

        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.

        17 Oct 2013
  33. User avatar

    Matthew Bastress

    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}
    07 Nov 2013
  34. User avatar

    Nathan Pye [Atlassian]

    Thanks Matthew, I have fixed it up now.

    07 Nov 2013
  35. User avatar

    Ron Chan

    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.

     

    15 Nov 2013
  36. User avatar

    Patrick Wiltrout

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

    21 Nov 2013
    1. User avatar

      Armen Khachatryan [Atlassian]

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

      22 Nov 2013
  37. User avatar

    Mehul Sanghvi

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

    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 ?

     

    25 Nov 2013
    1. User avatar

      Armen Khachatryan [Atlassian]

      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 https://support.atlassian.com, and we will go from there.

      Armen

      25 Nov 2013
      1. User avatar

        Mehul Sanghvi

        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 ? 

        25 Nov 2013
        1. User avatar

          Armen Khachatryan [Atlassian]

          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.

          26 Nov 2013
  38. User avatar

    Odin Odin

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

    03 Jan 2014
  39. User avatar

    Stephen Kestle

    `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

    15 Jan 2014
  40. User avatar

    Christopher Woodruff

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

    28 May 2014
  41. User avatar

    Oscar Baccay

    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
    Deployment
    17 Jun 2014
  42. User avatar

    Andrey Shovkoplyas

    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?

    02 Jul 2014
    1. User avatar

      Marcin Gardias [Atlassian]

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

      02 Jul 2014
      1. User avatar

        Andrey Shovkoplyas

        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}

        02 Jul 2014
  43. User avatar

    Andrey Shovkoplyas

    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

    04 Jul 2014
  44. User avatar

    Gerry Tan

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

    09 Jul 2014
    1. User avatar

      Philipp Scheit

      05 Mar 2015
  45. User avatar

    Rafał Łyczkowski

    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 ?

     

    29 Jul 2014
    1. User avatar

      Marcin Gardias [Atlassian]

      In Bamboo 5.5.1 branch build keys are no longer reused

      29 Jul 2014
  46. User avatar

    Akhil Kanaskar

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

    15 Jan 2015
  47. User avatar

    Sam Kenny

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

    15 Jan 2015
Powered by Confluence and Scroll Viewport