Variables in the YAML follow this format:
The flow provides three forms of variable substitution:
- system provided: substituted during the workflow compilation phase.
- context related: substituted in real time during the workflow execution.
- custom user provided: created and substituted in real time during the workflow execution
System Provided Variables
All system provided variables will also be automatically injected to any freestyle step.
||Branch name (or Tag depending on the payload json) of the Git repository of the main pipeline, at the time of execution.
You can also use
||The base branch used during creation of Tag|
||The pull request action|
||Commit message of the git repository revision, at the time of execution.
The messages quotes are escaped (i.e. ‘ is not ', “ is now ").
||Revision of the Git repository of the main pipeline, at the time of execution.
You can also use
||Will refer to the volume that was generated for the specific flow. Can be used in conjunction with a composition to provide access to your cloned repository.For example:test-server: volumes:
||Will refer to the mounted path of the workflow volume inside a Freestyle container.|
||Will be an indication of the current build was triggered: *build: The build was triggered from the build button * webhook: The build was triggered from a control version webhook|
||The build id. Note: use this variable as string with quotes to tag the image
||The timestamp the build was created. Note: use this variable as string with quotes to tag the image
||The URL to the build in Codefresh|
||Path to kubeconfig if exist|
|Any variable specified in the pipeline settings||For example, if you configure the pipeline settings with a variable named PORT, you can put the variable in your YAML build descriptor as
Context Related Variables
Context related variables are created dynamically during the workflow execution and according to the used steps.
|Working Directories||For example, you can set the working directory of step
|Images||You can set the candidate field of the push step with a variable named after a previously executed build step. Since the details of a created image are not necessarily known ahead of time, the variable can create an association to an optionally dynamic image name. Therefore, setting push step
Custom User Provided Variables
Custom variables can be created during the workflow execution inside of a freestyle step. Once a variable has been created it will:
- automatically be injected into any future freestyle step.
- automatically be used as composition variables for composition steps.
- will be used for substitutions in the yaml file just like the
system providedvariables are used in the compilation phase.
Custom variables are wiped clean on every pipeline execution, but are not modified as the steps progress.
Exporting environment variables from a freestyle step
In case you want to export environment variables from an existing step this is the way to do it
Codefresh exposes a file for each freestyle step that custom variables can be registered to. There are two ways to add variables to this file
Custom Variables Option a: Using cf_export cli
In case your freestyle step has sh installed, you can use our prepared cli that will enable you to easily add new variables.
You can either:
- explicitly state a VAR=VAL pair
state the name of an existing environment variable (like EXISTING_VAR).
Using the bash utility
Custom Variables Options b: Manually appending to the file
Appending variables manually can be useful in more complicated scenarios.
The variables file will be exposed inside the freestyle container in the following path:
You can use this technique to even inject a file with multiple variables.
When passing special characters through environmental variables
\ can be used as an escape character. For example if you were passing a cassandra connection string you might do something like
This will safely escape