Lifecycle hooks support for dev container features

[Chuxel]

This proposal is an enhancement idea to the current dev container features proposal.

---

Currently the proposed dev container features concept can update the contents of a container image and provide needed dev container configuration metadata to use those contents. The proposal includes an entrypoint property and this will run as non-interactive process with the default user for the container and is intended for things that should happen at the moment the container starts (like ENTRYPOINT in a Dockerfile) - this allows things like user modification that wouldn't be possible later.

However, there are situations where being able to affect something at a later lifecycle stage also makes sense. Lifecycle scripts run as the remoteUser and have remoteEnv and userEnvProbe processing applied to them. This allows commands like npm install to execute in the context of the correct user to ensure permissions and other factors are correctly handled.

I'd propose we make these properties available to features as well. For example:

1. Private features (e.g., when a feature is authored by someone in a devops / plat ops team) can enable sharing of standards and best practices within a team that can update over time without having to do a mass devcontainer.json update. Having the ability to use commands like postCreateCommand to fire something one time (e.g. registering a container with a management serrvice) would be very useful.
2. For scenarios like data science, it can be useful to provide features that encompass robust setup behaviors. For example, an analogous feature to "repo-to-docker" could be constructed for a one-stop-shop in getting a fully functional environment.

Similar to what is described in #18 and #19, we would want firing these commands to be baked into the image in some way in the case of pre-building such that you wouldn't need to reference the feature in devcontainer.json to get the benefits. Assuming we move forward with #18, that could be enough with the idea that the feature would copy any needed scripts to a well known location.

//cc @edgonmsft @jkeech @joshspicer @lostintangent @chrmarti @bamurtaugh

[jkeech]

To make sure I understand the proposal, is the idea that feature can contribute lifecycle hook additions? Say you have a feature that contributes a postStartCommand. That command would be run in addition to whatever user-provided postStartCommand exists when the devcontainer starts up?

This sounds like a great improvement to me. Features should be able to contribute partial devcontainer contents, so extending features to be able to contribute lifecycle hooks is a natural evolution of what features can do.

[Chuxel]

To make sure I understand the proposal, is the idea that feature can contribute lifecycle hook additions? Say you have a feature that contributes a postStartCommand. That command would be run in addition to whatever user-provided postStartCommand exists when the devcontainer starts up?

@jkeech Yep!

I actually did this in the devpacks prototype to prove out #18 by just semi-colon concatenating. That didn't use features since each Buildpack injected its metadata, but it seemed to work well. We could get a bit more durable than that with whatever the implementation was here, but it was quite handy there,

[bamurtaugh]

I really like this idea too! It supports the goal of providing modular pieces for creating dev containers. And depending on an end user's familiarity with lifecycle scripts, they could instead just use one contributed by a feature author, thus not needing expertise in the implementation details.

[jkeech]

There have been some other scenarios discussed internally where this would be useful, such as building IDE indexes based on the source code which can't be done at image build time before the repo is cloned in, but it can be done at later in the lifecycle.

You could imagine a feature for IntelliJ or RubyMine which both installs a remote server in the image and adds an updateContentCommand or onCreateCommand lifecycle hook that indexes the repo contents.

[edgonmsft]

Sounds great! Every thing that allows features to encapsulate more and more of the configuration users need to run something should help a lot.

[metaskills]

Thanks for this... I would totally use this feature. Still having issues moving a few of our private features over from postCreate repo clone and run scripts hacks. Tho we an likely work around it now ( I think ) a feature like this would give us all the tools we need.

[jkeech]

This proposal has been implemented! #181 is tracking finalization of this proposal and is a good place to leave feedback/comments.