In CDS, it is possible to define variables at different levels:
Existing variable types:
All variables in CDS can be invoked using the simple {{.VAR}} format. To simplify the use between all the variable sources, we have defined the following prefixes:
{{.VAR}}{{.cds.VAR}}{{.git.VAR}}{{.cds.pip.VAR}}{{.cds.app.VAR}}{{.cds.env.VAR}}{{.cds.proj.VAR}}{{.cds.build.VAR}}Here is the list of builtin variables, generated for every build:
{{.cds.environment}} The name of the current environment{{.cds.application}} The name of the current application{{.cds.job}} The name of the current job{{.cds.manual}} true if current pipeline is manually run, false otherwise{{.cds.pipeline}} The name of the current pipeline{{.cds.project}} The key of the current project{{.cds.run}} Run Number of current workflow, example: 3.0{{.cds.run.number}} Number of current workflow, example: 3 if {{.cds.run}} = 3.0{{.cds.run.subnumber}} Sub Number of current workflow, example: 4 if {{.cds.run}} = 3.4{{.cds.stage}} The name of the current stage{{.cds.status}} Status or previous pipeline: Success or Failed{{.cds.triggered_by.email}} Email of the user who launched the current build{{.cds.triggered_by.fullname}} Full name of the user who launched the current build{{.cds.triggered_by.username}} Username of the user who launched the current build{{.cds.version}} The current version number, it’s an alias to {{.cds.run.number}}{{.cds.workflow}} The name of the current workflow{{.cds.workspace}} Current job’s workspace. It’s a directory. In a step script, {{.cds.workspace}} == $HOME{{.payload}} The current payload in JSON format{{.cds.version}}
CDS version is a builtin variable, it is transmitted through pipelines of a workflow run.
In a step of type script, you can export a variable as the following:
$ worker export varname thevalue
You can use the build variable in:
{{.cds.build.varname}}{{.cds.build.varname}}{{.workflow.pipelineName.build.varname}} with pipelineName the name of the pipeline in your workflowSee worker export documentation
All CDS variables, except password type, can be used as plain environment variables.
Theses lines will have the same output
echo '{{.cds.parent.application}}'
echo $CDS_PARENT_APPLICATION
Here is the list of git variables:
{{.git.hash.before}}: SHA of the most recent commit before the push{{.git.hash}}: SHA of the most recent commit after the push{{.git.hash.short}}: Short version of git.hash{{.git.hook}}: Name of the event that trigger the run{{.git.url}}: Git ssh URL used to clone{{.git.http_url}}: Git http url used to clone{{.git.branch}}:
{{.git.tag}}: Name of the tag that triggered the run{{.git.author}}: Name of the most recent commit author{{.git.author.email}}: Email of the most recent commit author{{.git.message}}: Git message of the most recent commit{{.git.server}}: Name of the repository manager{{.git.repository}}:
Here is the list of git variables available only for Bitbucket server
{{.git.hash.dest}}: SHA of the most rcent commit on destination branch ( PullRequest event ){{.git.branch.dest}}: Name of the destination branch on a pull request event{{.git.repository.dest}}: Name of the target repository on a pull request event{{.git.pr.id}}: Identifier of the pullrequest{{.git.pr.title}}: Title of the pullrequest{{.git.pr.state}}: Status of the pullrequest{{.git.pr.previous.title}}: Previous title of the pullrequest{{.git.pr.previous.branch}}: Previous target branch of the pullrequest{{.git.pr.previous.hash}}: Previous target hash of the pullrequest{{.git.pr.previous.state}}: Previous status of the pullrequest{{.git.pr.reviewer}}: Name of the reviewer{{.git.pr.reviewer.email}}: Email of the reviewer{{.git.pr.reviewer.status}}: Status of the review{{.git.pr.reviewer.role}}: Role of the reviewer{{.git.pr.comment}}: Comment written by the reviewer{{.git.pr.comment.before}}: Previous comment{{.git.pr.comment.author}}: Author name of the comment{{.git.pr.comment.author.email}} Author email of the commentOn a pipeline, you can add some parameters, this will let you to use {{.cds.pip.param_name}} in your pipeline.
version: v1.0
name: build
parameters:
param_name:
type: string
default: default_value
stages:
...
This will let you to use {{.cds.pip.param_name}} in your pipeline.
Then, in the workflow, you can set the value for pipeline parameter in the pipeline context.
name: test-workflow
version: v2.0
workflow:
the-pipeline:
pipeline: build
parameters:
varname: the-value
...
You can use a Git or Builtin variable. example:
name: test-workflow
version: v2.0
workflow:
the-pipeline:
pipeline: build
parameters:
varname: {{.cds.version}}
varname2: {{.cds.pip.param_name}}
...
Notice that you can’t create a pipeline parameter of type password. If you want to use a variable of type password, you have to create it in your project / application or environment. Then, in your workflow, use this variable to set the value of the pipeline parameter - the pipeline parameter can be of type string.
You can also access a pipeline parameter myparam of the pipeline mypipeline from another pipeline in the same workflow using {{.workflow.mypipeline.pip.myparam}}.
Some helpers are available to transform the value of a CDS Variable.
Example: run a pipeline, with an application named my_app. A step script:
echo "{{.cds.application | upper}}"
will display
MY_APP
Helpers available and some examples:
{{.cds.application | upper}}{{.cds.application | lower}}{{.cds.application | replace "_" "."}}{{.cds.application | default ""}}, {{.cds.application | default "defaultValue"}}, {{.cds.app.foo | default .cds.app.bar .cds.app.biz }}You can use CDS Variables with default helpers:
{{.cds.app.foo | default .cds.app.bar }}
You can use many helpers:
{{.cds.app.foo | upper | lower}}
{{.cds.app.foo | default .cds.app.bar | default .cds.app.biz | upper }}
Are you a Go developer? See all helpers on https://github.com/ovh/cds/blob/v0.54.1/sdk/interpolate/interpolate_helper.go#L23 and some unit tests on https://github.com/ovh/cds/blob/v0.54.1/sdk/interpolate/interpolate_test.go#L72