- Notifications
You must be signed in to change notification settings - Fork1.1k
feat: add support forcoder_env#11102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
d18e00c tob63880bCompareb63880b to04ac5ccCompare0fc68f9 to983cad8CompareUh oh!
There was an error while loading.Please reload this page.
johnstcn left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I think this behaviour is fine.
LGTM
There's definitely a set of environment variables we don't want folks to be able to override, lest they brick their workspace.
So this behaviour of not overriding is fine for now.
Perhaps later we could have a denylist of environment variables, but that's not for now.
Uh oh!
There was an error while loading.Please reload this page.
This PR adds support for
coder_env(coder/terraform-provider-coder#174).The terraform/proto structure is conducive towards allowing additional logic in the future, as discussed in#10166.
For now, we simply piggy-back on the
workspace_agents.environment_variablescolumn with the additional envs. It felt premature to add a separate table and logic in the agent for this, however,a downside is that conflicts are silently ignored (we simply don't set the env if it's already set on the agent resource or by another module).Ideas for non-silent discard are welcome. And if preferred, I can create the
workspace_agent_envtable with accompanying agent logic to process the extra envs. The agent can then log the conflict.Fixes#10166