@matifali Regarding implementation, should we limit the ability to invoke coder [agent] env set to coder_scripts only?

This would let us implement it in a way where the envs are ephemeral, i.e. they don't stick around if the agent is restarted (they need to be re-set by script). We also don't need any API endpoints on coderd to implement it.

Optionally we can also allow manual invocation within the workspace, but I think if a user needs that, dotfiles are probably a more appropriate location.

If we allow for other use-cases wrt setting envs, I'm afraid it might lead to confusion of when they apply and when they don't. For instance, does a workspace stop/start wipe the env, or persist it? Does it apply to all agents or only one? Etc.

@mafredri Good questions.

should we limit the ability to invoke coder [agent] env set to coder_scripts only?

I think we should not limit the use but can assume that they will be primarily set in coder_script resources.

coder [agent] env set

What does this mean? It's not a good UX if a user manually specifies the agent name. If I am correct, coder_script or a coder_worksapce is linked to a single coder_agent, so it should be sufficient for a user to use coder env set only.

For instance, does a workspace stop/start wipe the env, or persist it?

A stop is usually stopping/destroying a VM or container so the envs will be destroyed. The user or the coder_script should set them again on the next start. We should not treat them as files, and I think it's okay to not persist them in this case.

Optionally we can also allow manual invocation within the workspace, but I think if a user needs that, dotfiles are probably a more appropriate location.

I agree. We should not block this use-case.

What does this mean? It's not a good UX if a user manually specifies the agent name. If I am correct, coder_script or a coder_worksapce is linked to a single coder_agent, so it should be sufficient for a user to use coder env set only.

Oh, sorry it was unclear, I was not referring to specifying the agent, instead I was suggesting we might put the command under coder agent env set instead of coder env set because we don't want to support it outside the workspace. (I think this might also have the benefit of giving better understanding of how it's applied, i.e. only to this running agent.)

I don't think it'd be nice UX if we had the command there, but it said "this can only be run inside the workspace", but then again, maybe that's OK.

I agree. We should not block this use-case.

By not blocking, are you referring to that we should allow manual coder agent env set invocations by the user?

By not blocking, are you referring to that we should allow manual coder agent env set invocations by the user?

Yes

Oh, sorry it was unclear, I was not referring to specifying the agent, instead I was suggesting we might put the command under coder agent env set instead of coder env set because we don't want to support it outside the workspace. (I think this might also have the benefit of giving better understanding of how it's applied, i.e. only to this running agent.)

I still prefer the coder env set We can exit with a message that it's only allowed in a workspace. But probably you are right. coder env set can be used later once we decide to add user-scoped variables. So its ok to go with coder agent env set. your choice :)

What do you think @bpmct?

After a discussion on Slack we came to the conclusion that there's no real need for this at this time. It's preferable to set environments declaratively in Terraform. Setting them in run-time introduces a race between starting processes and scripts modifying the environment as changes won't propagate to old processes.

Use-cases like refreshing tokens can be by wrapping binaries that need to perform authentication. Such use-cases can be amended by #11131.

If the need arises, we can re-open.