Features: Append to onCreateCommand, postCreateCommand or updateContentCommand

[virtualstaticvoid]

Hello,

I'm writing a feature which requires writing configuration files to the home directory of the user within the container.

Much like the devcontainer-feature.json properties containerEnv, init and securityOpt are added to the configuration when the dev container is run, feature authors could add commands which get executed during the processes of running onCreateCommand, postCreateCommand or updateContentCommand.

These commands are run within the context of the remoteUser such that the $HOME environment variable is correct, any files created will have the correct permissions (w/o needing fix by chmoding), and the project directory would be mounted, which opens up many more possibilities for configuration based off project settings.

For example, I want to create a feature which installs asdf version manager. Developers manage their plugin versions with the .tool-versions file, which is typically located in the root directory of their project. It would be neat if my feature could add to postCreateCommand so that a step to run the asdf install, which reads .tool-versions to install tool plugins, could be executed without the developer needing to include this step in their devcontainer.json file.

Another examples include writing to ~/.bashrc, AWS configuration defaults to ~/.aws, Azure config to ~/.azure, Kubernetes config to ~/.kube etc.

Related to #91

[Chuxel]

@virtualstaticvoid is what you are thinking about like #60 ? Also, curious if some of the priv issues you mentioned could be helped by #25

[virtualstaticvoid]

Yeah, #60 describes what I was thinking.

... there are situations where being able to affect something at a later lifecycle stage ...
... having the ability to use commands like postCreateCommand to fire something one time ...
.. baked into the image ... such that you wouldn't need to reference the feature in devcontainer.json

#25 is somewhat different though. I was reflecting on how if feature installation tasks were executed via postCreateCommand they would be in the correct user context, thus implicitly solving (some of) the issues described in #25.

I think #25 highlights a broader issue with the architecture of devcontainers, but that's a topic for another post/discussion perhaps.

I'll close this issue.