coder
Allow modules require specific Coder version
If a module relies on a new feature in Coder, we should have a way to detect/prevent it from being used on old versions
@kylecarbs any thoughts on how we can do this?
My idea is to add a property to such modules let's say MINIMUM_CODER_VERSION="2.6.0" and then check during run.sh execution if the coder version is satisfied.
We could probably do this in Terraform, too, if we have a way to get the coder version in Terraform.
Don't we already do this? For example:
https://github.com/coder/modules/blob/a9a58bff324e92488c2a873440688374bdd278db/dotfiles/main.tf#L4-L9
I think the best place for this is terraform, since runtime (script) failure means late detection of issues / non-functional workspace after build.
@mafredri This Coder provider. We are talking about the Coder version. e.g. v2.7.2
An example is a module that depends on the coder agent env set command(when added). It should fail if added to older Coder deployments
@matifali Ah, I see.
I'd say, the coder terraform provider could expose coder version and we could validate that in the module. It'd be nice to represent this in a way where we can easily expose the information in the registry too.
We could add a new data source, like coder_deployment:
coder_deployment "me" {}
something {
lifecycle {
postcondition {
condition = check_version(coder_deployment.me.version)
error_message = "Coder deployment version must be higher than XXX."
}
}
}
Or maybe it can be a separate resource with param, like:
resource "coder_deployment" "some_module" {
require_version = ">=1.0.0"
}
@mafredri Hmm or something we can add to coder_workspace or the agent. As the scripts are being run by the agent so something like coder_agent.example.version or data.coder-workspace.me.coder_version
and then used along with
something {
lifecycle {
postcondition {
condition = check_version(coder_agent.example.version)
error_message = "Coder deployment version must be higher than XXX."
}
}
}
@matifali I suppose that's an option, although terraform doesn't have any better idea of what version of the agent is truly going to run. So I think checking the deployment version is a good approximation (ideally, latest agent should be downloaded on start).
I don't have any strong opinions on that, though.
One simple change we definitely can make is expose a CODER_{MODULE_}AGENT_VERSION=v1.0.0 env that's always present in scripts. This can be used for primary or additional verification, or handling fallbacks.
@mafredri Exposing is not a problem I think. We can already get the version within a script using something like coder version | head -n 1 | awk '{print $2}' | awk -F"-" '{print $1}' | sed 's/v//'
I am wondering if it's ok to do it in scripts or if we should/can do it in Terraform. The benefit of doing it in Terraform is we can fail at build stage instead of the coder_script.
Can we have this built-in to the coder provider? For example to use coder provider v0.17.0 one needs to be on Coder version 2.8.3+. The idea is that installing provider will fail if run on a lower version of Coder with an actionable error message in template build logs.