You can create custom flows for a template, that allow 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).
Create a file named env0.yml to define a custom flow. env0 will use this file it is defined.
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
Handling errors
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".
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
Exposed env0 System Environment Variables
env0 exposes the following environment variables for you to use:
Variable Name | Value Description |
|---|---|
| The deployed Environment ID |
| The Project ID of the deployed Environment |
| The deployment ID |
| The Terraform Workspace name used in the Environment |
| Your env0 organization ID |
| The deployed Template ID |
| 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.
The Deployment Container
Our deployment container is based on node:12-alpine and includes the following:
Includes | Version |
|---|---|
Bash | 5.0.11(1)-release |
NodeJS | 12.18.3 |
NPM | 6.14.6 |
YARN | 1.22.4 |
GIT | 2.24.3 |
Python2 | 2.7.18 |
Python3 | 3.8.2 |
pip3 | 20.2 |
pip2 | 18.1 |
AWS CLI | 1.18.115 |
Google Cloud SDK | 304.0.0 |
Azure CLI | 2.10.1 |
kubectl | 1.15.11 |
tfenv | 1.0.1 |
Terraform default version | 0.12.24 |
jq | jq-master-v20191114-85-g260888d269 |
OpenSSL | 1.1.1g |
Powershell | 7.0.3 |
infracost | 0.8.4 |
Adding additional binaries to the container
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.
Updated 15 days ago