Hello, again env0 fans! We have a lot of awesome stuff for you today. Several features in this blog worth noting, and another blog entirely dedicated to our new Terraform Provider! We have been hard at work putting new stuff into the platform to make your life easier. User Experience is our top priority, so we are always working to ensure the easiest experience, and not overloading the platform with unnecessary features that get in the way. So let’s get into it!
Cost Estimation
This one is a great one to start with. We are adding on to our already outstanding environment cost features. By now, you already know about how we use our open-source project Terratag combined with read-only credentials to your clouds’ billing API to provide you with graphs of actual cost over time, correlated to deployments:
To add this new feature, we’ve now stepped back in time…. in the deployment process, that is. We have added the ability to enable Cost Estimation to your projects. With the power of Infracost in your deployment process, this enables the ability to see an estimation of what your deployment will cost.
Neat, huh? If this is a change to an already deployed environment, you’ll even be able to see the cost difference this deployment will have. This really helps you to have a full picture of who, what, where, when, and how much, when you are reviewing and making a decision on whether to approve a deployment or not. Enabling this feature is as easy as clicking a single checkbox in the Policies Tab under Project Settings!
Oh, and one more little tidbit. Curious how a Pull Request affects the cost? No problem! We’ll drop that cost estimate output right into your Pull Request Plan comment!
Terraform Version (per Template)
This one is simply a convenience feature. Our runtime container used for deployments has the default Terraform version of 0.12.24. But, we know that not all of your code or modules use the same version. So we have had the ability to use whatever Terraform version you want. Specifying the version in your code, or using an environment variable to specify it, would allow us to get the required version on Terraform Init, and execute it. Now, we give you the quick and convenient way of simply specifying it in a dropdown list from the Template settings:
Of course, if you want to continue to use your Terraform code to specify the needed version, no worries. You can always select Resolve from terraform code, from the drop-down. And if you don’t specify anything, we’ll default to 0.12.24, which is what defaults in our runtime container. For more information, check out the documentation.
Glob Filtering
We’ll end this blog with a glob...filter. “What is a glob filter”, you ask? Well, that’s easy. In computer programming, glob patterns specify sets of filenames with wildcard characters. We now allow you to specify glob patterns for Plan on Pull Request and for Continuous Deployment. For example, you can configure pattern like
src/project_1/**
In this case, we will re-deploy only if the push contains file which starts with src/project_1/...
Or
*.txt
In this case, we will re-deploy only if the push contains .txt files.
You can configure glob filtering from the Triggers tab in an environment:
This should prove to be very useful for our mono-repository structured users, or users who implement a module-based IaC strategy. Enjoy!
Hello, again env0 fans! We have a lot of awesome stuff for you today. Several features in this blog worth noting, and another blog entirely dedicated to our new Terraform Provider! We have been hard at work putting new stuff into the platform to make your life easier. User Experience is our top priority, so we are always working to ensure the easiest experience, and not overloading the platform with unnecessary features that get in the way. So let’s get into it!
Cost Estimation
This one is a great one to start with. We are adding on to our already outstanding environment cost features. By now, you already know about how we use our open-source project Terratag combined with read-only credentials to your clouds’ billing API to provide you with graphs of actual cost over time, correlated to deployments:
To add this new feature, we’ve now stepped back in time…. in the deployment process, that is. We have added the ability to enable Cost Estimation to your projects. With the power of Infracost in your deployment process, this enables the ability to see an estimation of what your deployment will cost.
Neat, huh? If this is a change to an already deployed environment, you’ll even be able to see the cost difference this deployment will have. This really helps you to have a full picture of who, what, where, when, and how much, when you are reviewing and making a decision on whether to approve a deployment or not. Enabling this feature is as easy as clicking a single checkbox in the Policies Tab under Project Settings!
Oh, and one more little tidbit. Curious how a Pull Request affects the cost? No problem! We’ll drop that cost estimate output right into your Pull Request Plan comment!
Terraform Version (per Template)
This one is simply a convenience feature. Our runtime container used for deployments has the default Terraform version of 0.12.24. But, we know that not all of your code or modules use the same version. So we have had the ability to use whatever Terraform version you want. Specifying the version in your code, or using an environment variable to specify it, would allow us to get the required version on Terraform Init, and execute it. Now, we give you the quick and convenient way of simply specifying it in a dropdown list from the Template settings:
Of course, if you want to continue to use your Terraform code to specify the needed version, no worries. You can always select Resolve from terraform code, from the drop-down. And if you don’t specify anything, we’ll default to 0.12.24, which is what defaults in our runtime container. For more information, check out the documentation.
Glob Filtering
We’ll end this blog with a glob...filter. “What is a glob filter”, you ask? Well, that’s easy. In computer programming, glob patterns specify sets of filenames with wildcard characters. We now allow you to specify glob patterns for Plan on Pull Request and for Continuous Deployment. For example, you can configure pattern like
src/project_1/**
In this case, we will re-deploy only if the push contains file which starts with src/project_1/...
Or
*.txt
In this case, we will re-deploy only if the push contains .txt files.
You can configure glob filtering from the Triggers tab in an environment:
This should prove to be very useful for our mono-repository structured users, or users who implement a module-based IaC strategy. Enjoy!
.png)
