For now, we simply piggy-back on theworkspace_agents.environment_variables column 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 theworkspace_agent_env table with accompanying agent logic to process the extra envs. The agent can then log the conflict.

Fixes#10166

github-actionsbot assignedmafredri

Dec 8, 2023

mafredri force-pushed themafredri/feat-coder-env branch 2 times, most recently fromd18e00c tob63880bCompare

December 8, 2023 14:41

feat: add support forcoder_env

04ac5cc

Fixes#10166

mafredri force-pushed themafredri/feat-coder-env branch fromb63880b to04ac5ccCompare

December 8, 2023 15:14

add fill resource default

983cad8

mafredri force-pushed themafredri/feat-coder-env branch from0fc68f9 to983cad8Compare

December 8, 2023 15:46

mafredri requested review fromjohnstcn,matifali andmtojek

December 8, 2023 15:49

mafredri marked this pull request as ready for review

December 8, 2023 15:49

matifali reviewed

Dec 8, 2023

View reviewed changes

coderd/provisionerdserver/provisionerdserver.goShow resolvedHide resolved

johnstcn approved these changes

Dec 8, 2023

View reviewed changes

Copy link

Member

johnstcn left a 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.