Thank you for sharing your feedback. We are happy that you found the provider useful.

The environment where we use the coderd provider (e.g. CI/CD pipeline) may not have the required credentials to run a terraform plan for the said template.

You're right, the issue seems to be more with coder itself because coder does not offer a way to validate templates before pushing them

coder does not offer a way to validate templates before pushing them

To validate a template, Coder needs the terraform binary, and the machine pushing the template may not have it installed or, even if installed, may not have authentication to create template resources. So, the best place to validate is to push to the provisioner and validate where it will eventually be applied (terraform apply).

We can investigate this behavior further in a discussion on coder/coder.

Closing this as it's outside the scope of the provider.

The recommended workflow for debugging a template is to just terraform apply to push it to the provisioner, and observe any errors. It won't be marked active if the build fails there, so this is safe.
This is the same process as when debugging a template to be created via the Web UI or CLI. However, with #95, it'll be a lot easier!

coder does not offer a way to validate templates before pushing them

To validate a template, Coder needs the terraform binary, and the machine pushing the template may not have it installed or, even if installed, may not have authentication to create template resources. So, the best place to validate is to push to the provisioner and validate where it will eventually be applied (terraform apply).

We can investigate this behavior further in a discussion on coder/coder.

@matifali If I can run a terraform plan I would assume I have the terraform binary installed.
Regarding the authentication, this should also be given when I can run a terraform plan on the coderd project, shouldn't it?

Closing this as it's outside the scope of the provider.

The recommended workflow for debugging a template is to just terraform apply to push it to the provisioner, and observe any errors. It won't be marked active if the build fails there, so this is safe. This is the same process as when debugging a template to created via the Web UI or CLI. However, with #95, it'll be a lot easier!

@ethanndickson I'm worried that this will cause issues when pushing a broken template (maybe not in code, but in logic) because I have no way of validating the changes in a test workspace first.
Or did I understand something wrong?

Having separate versions like in your example (with the staging and stable version) would provoke code duplicity which is what I was aiming to reduce when switching to the coderd provider

By authentication I mean authenticating to the provisioner. For example you may have a k8s template but no access to the cluster locally on your machine where you are running terraform plan. Same for docker, assuming your local client machines don't have access to the docker host where workspaces will be created.

The same argument applies for cloud provider templates and a local client probably will not have access to provision/plan resources on the cloud.

So the best place to validate is the provisioner.

As a workaround you can make sure your local terraform is authenticated with infrastructure providers and run a terraform fmt, terraform validate and terraform plan on the template before pushing it to the Coder using the CLI, API or the coderd provider. You can also do this as part of your CI and fail early if something is not as expected.

Yes, this is what I was doing until I started using coderd. Was hoping it would be possible to omit that.