Unfortunately, the first option is too rigid for my liking (too much babysitting to perform upgrades) and the latter is too aggressive/disruptive for my liking (it could switch to a new minor version, e.g., 1.9.1 or even a major version, e.g., 2.0.1).
Just to set the stage, TF, itself uses this kind of thing in versions.tf (this is just one example):
terraform {
required_version = "~> 1.8.3"
}
It would be ideal if could just read the terraform.required_version requirements from the HCL of the repo/directory that the pipeline deals with.
If not that, it would be nice to have a similar facility for specifying the version constraints of the task.
E.g.:
- task: TerraformInstaller@1
inputs:
terraformVersion: '~> 1.8.3'
# or like docker image conventions:
# terraformVersion: `1.8.3` # task currently supports this
# terraformVersion: `1.8` # latest 1.8.x - task doesn't currently support this
# terraformVersion: `1` # latest 1.x.x - task doesn't currently support this
Potential enhancement request.
It seems I can do one of two things:
1.8.3
latest
Unfortunately, the first option is too rigid for my liking (too much babysitting to perform upgrades) and the latter is too aggressive/disruptive for my liking (it could switch to a new minor version, e.g.,
1.9.1
or even a major version, e.g.,2.0.1
).Just to set the stage, TF, itself uses this kind of thing in
versions.tf
(this is just one example):It would be ideal if could just read the
terraform.required_version
requirements from the HCL of the repo/directory that the pipeline deals with.If not that, it would be nice to have a similar facility for specifying the version constraints of the task.
E.g.: