...
width | 64% |
---|
...
...
...
...
...
...
...
...
...
Variable substitution
Variables are substituted in all
...
task configuration text fields (e.g. Stack Name, Template URL, Instance ID, Volume ID etc.).
Tip | ||
---|---|---|
| ||
Configuration as code is not yet natively supported in Bamboo. You can partially work around this limitation as outlined in How to provide task configuration from an external source like a file. |
Note | ||
---|---|---|
|
...
| |
Tasks may emit sensitive data like credentials which are not supposed to surface in build logs - this can be achieved as follows:
|
Variable
...
definition
Variables are defined by most
...
tasks for reuse in subsequent
...
tasks,
...
...
for details, and each task's documentation for example log outputs.
...
- A task's generated variables might get amended with respective AWS API additions over time - a live build log will always provide the most current variable shape accordingly.
- We are contemplating to evolve the current key/value based approach to one based on hierarchical JSON payloads, please watch/vote/comment on the following issue to guide our resp. roadmap:
Jira Legacy server JIRA (utoolity.atlassian.net) serverId fac61c2e-db0a-39da-bb3c-e0dc0ef556f0 key UAA-92
Example
This example illustrates the variable generation pattern:
- variables have a dedicated prefix
...
- like
bamboo.custom.aws.*
,
...
- with
*
...
- being a task specific prefix, e.g.
bamboo.custom.aws.cloudformation.stack
- variables referring to a collection of resources provide their ids in a semicolon separated list (i.e. the same format available on input), e.g.
${bamboo.custom.aws.ec2.instance.resources}
...
- with values
i-a316b842;i-b4210842 (line 2)
you can refer to these variables from subsequent tasks via something
...
like
${bamboo.custom.aws.ec2.instance.resources.i-a316b842.PrivateDnsName}
(line 6)
- however, given script access to such a named resource is difficult, there is a shortcut to ease reusing the first (and often only) affected resource via something
...
like
${bamboo.custom.aws.ec2.instance.first.i-a316b842.PrivateDnsName}
:(line 19)
Code Block language text linenumbers true Creating common variables for 2 resources affected by task: ... bamboo.custom.aws.ec2.instance.resources: i-a316b842;i-b4210842 Creating resource variables for instance 'i-a316b842': ... bamboo.custom.aws.ec2.instance.resources.i-a316b842.InstanceId: i-a316b842 ... bamboo.custom.aws.ec2.instance.resources.i-a316b842.State: running ... bamboo.custom.aws.ec2.instance.resources.i-a316b842.PrivateDnsName: ip-10-0-0-241.ec2.internal ... bamboo.custom.aws.ec2.instance.resources.i-a316b842.PrivateIpAddress: 10.0.0.241 ... bamboo.custom.aws.ec2.instance.resources.i-a316b842.PublicDnsName: ... bamboo.custom.aws.ec2.instance.resources.i-a316b842.PublicIpAddress: null ... bamboo.custom.aws.ec2.instance.resources.i-a316b842.LaunchTime: 20150716T080402Z ... bamboo.custom.aws.ec2.instance.resources.i-a316b842.tags: Name ... bamboo.custom.aws.ec2.instance.resources.i-a316b842.tags.Name: taws-it-2.0.0 Creating resource variables for instance 'i-b4210842': ... <skipped> Creating common variables for first resource affected by task: Creating resource variables for instance 'i-a316b842': ... bamboo.custom.aws.ec2.instance.first.InstanceId: i-a316b842 ... bamboo.custom.aws.ec2.instance.first.State: running ... bamboo.custom.aws.ec2.instance.first.PrivateDnsName: ip-10-0-0-241.ec2.internal ... bamboo.custom.aws.ec2.instance.first.PrivateIpAddress: 10.0.0.241 ... bamboo.custom.aws.ec2.instance.first.PublicDnsName: ... bamboo.custom.aws.ec2.instance.first.PublicIpAddress: null ... bamboo.custom.aws.ec2.instance.first.LaunchTime: 20150716T080402Z ... bamboo.custom.aws.ec2.instance.first.tags: Name ... bamboo.custom.aws.ec2.instance.first.tags.Name: taws-it-2.0.0
...
variables are also available as environment variables in
...
the Script
...
task for example, albeit named slightly different, e.g.
$bamboo_custom_aws_cfn_stack_StringWithRegex
(Unix)
...
or
%bamboo_custom_aws_cfn_stack_StringWithRegex%
(Windows)
...
variables are locally scoped and thus only reusable in subsequent tasks and not in other jobs/stages due to the implied concurrency, see the
...
following discussion and workaround
...
Contextual entity variables
Insert excerpt | ||||||
---|---|---|---|---|---|---|
|
Refer to Injecting contextual entity variables into task configurations for details.