You can create custom flows for a template, that allows you to run whatever you want (bash, python, gcloud, Ansible, CloudFormation, etc.), whenever you want in the deployment process (before or after Terraform init/plan/apply, and even destroy/error).
For specific custom flow per template:
Create a file named env0.yml under the template folder. env0 will use this file when is defined.
For sharing custom flow for all templates:
Create a file named env0.yml under the root folder. env0 will use this file when it is defined and the template folder doesn't define this file.
Working Directory for env0.yml
env0 will run custom flow commands with a working directory based on where the file was taken.
Based on that you can reference your commands to other scripts/commands by using "./script.sh"
Below is an example of a custom flow which creates a more "dynamic" Terraform file, based on an environment variable value, and uses Python and Jinja before the Terraform Init (the full example of this template git repo (including the env0.yml file) is here):
version: 1 deploy: steps: terraformInit: before: - pip install --user j2cli - 'echo Generating "stage.auto.tfvars" for "$STAGE"' - j2 stage.auto.tfvars.j2 > stage.auto.tfvars - 'echo -e "Generated \"stage.auto.tfvars\": \n$(cat stage.auto.tfvars)"' - 'echo Generating "elb.tf" for "$STAGE"' - j2 elb.tf.j2 > elb.tf - 'echo -e "Generated \"elb.tf\": \n$(cat elb.tf)"'
You can include the following possible hooks in an env0.yml file:
version: type: number deploy: onCompletion: - type: string onSuccess: - type: string onFailure: - type: string steps: setupVariables: after: - type: string terraformInit: before: - type: string after: - type: string terraformPlan: before: - type: string after: - type: string terraformApply: before: - type: string after: - type: string storeState: before: - type: string after: - type: string terraformOutput: before: - type: string after: - type: string destroy: onCompletion: - type: string onSuccess: - type: string onFailure: - type: string steps: setupVariables: after: - type: string terraformInit: before: - type: string after: - type: string terraformPlan: before: - type: string after: - type: string terraformDestroy: before: - type: string after: - type: string
If any command in your custom flow returns a non-zero exit code, the env0 deployment will stop on a 'Failed' status. You can leverage this to perform validation - for example - asserting a certain environment variable was supplied.
In such a case, env0 will display any output from
stderr as the deployment error. If no output is found in
stderr, it will be shown as an "Unknown Error".
Error Message Handling
Use the following notation
1>&2to redirect stdout messages to stderr. This allows env0 to display the message in its UI. (see I/O Redirection)
Here is an example -
version: type: 1 deploy: steps: setupVariables: after: - if [ -z "$MY_VAR" ]; then echo "MY_VAR must be supplied" 1>&2 && exit 1; fi
env0 exposes the following environment variables for you to use:
The deployed Environment ID
The Project ID of the deployed Environment
The deployment ID
The Terraform Workspace name used in the Environment
The root repository path
Your env0 organization ID
The deployed Template ID
The deployed Template path
The deployed Template name
The deployed Template name
The name of the environment creator
The email of the environment creator
The name of the deployer
The email of the deployer
GitHub- the username PR author.
The source branch of the PR
The target branch of the PR
The commit hash of deployed Environment
See this sample of using these variables in our public templates repo.
Our deployment container is based on node:14.16.0-alpine and includes the following:
Google Cloud SDK
Terraform default version
You can bring your own docker image, extending env0's default image (which is based on node:12-alpine), in case you are using our Self-Hosted Agent.
In order to learn more about custom docker images, please contact our support team.
You can easily download any binary needed using the
curl command in all steps. You can also place that new binary under
opt folder in case you need it within your PATH.
Q. How can I export my own Environment Variable to use downstream?
At this time, this isn't possible. Each line is executed in a separate session. If you need to run multiple steps within one hook, we suggest creating and executing a single script (.sh) file. Another suggestion is to store variables on to the filesystem (e.g. json file).
Q. How can I use Custom Flows to add new Terraform Variables?
Since its currently not impossible to create new Environment Variables inside the custom flow, the recommended approach to adding terraform variables is to use variable definitions files, specifically the
*.auto.tfvars.json files to pass additional variables to your Terraform code. Note: Please be aware of the Terraform Variable Definition Precedence order as defined here: https://www.terraform.io/docs/language/values/variables.html#variable-definition-precedence
Updated 1 day ago