Allow modules require specific Coder version about modules HOT 9 OPEN

@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.

from modules.

@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.

from modules.

@mafredri what are you doing thoughts on this? See my comment above.

from modules.

Don't we already do this? For example:

I think the best place for this is terraform, since runtime (script) failure means late detection of issues / non-functional workspace after build.

from modules.

@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

from modules.

@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"
}

from modules.

@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."
    }
  }
}

from modules.

@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.

from modules.

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.

from modules.