Lifecycle hooks support for dev container features · Issue #60 · devcontainers/spec (original) (raw)

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