[proposal] Allow Features to contribute lifecycle hooks

[joshspicer]

relevant to: #60

Proposal

Introduce the following properties to devcontainer-feature.json, mirroring the behavior and syntax of the devcontainer.json lifecycle hooks.

• "onCreateCommand"
• "updateContentCommand"
• "postCreateCommand"
• "postStartCommand"
• "postAttachCommand"

Example

{
   "id": "my-feature",
   "version": "1.0.0"
   "postCreateCommand": "./myScript.sh"
}

Lifecycle scripts are looked up relative to the root of the Features source directory, which is bundled up as an archive when distributed. Features already support distributing arbitrary scripts via the registry, this proposal will now allow the Feature to contribute to the build's lifecycle system.

Feature lifecycle hooks will be prepended to the lifecycle hooks (if any) declared by the current devcontainer.json. Lifecycle hooks will be prepended in the order that the Feature's installation script was executed. Commands will be joined in such a way that a failure in any one lifecycle hook, will indicate a failure for that entire lifecycle hook execution.

[bamurtaugh]

Should we label this with finalization, now that the proposal is merged into the spec?

[eitsupi]

Hi, I want use this functionality to JuliaLang/devcontainer-features#9

Is there a recommended path for scripts to be placed in containers at this time?
For example, at the moment this is placed on a path like /julia-devcontainer-scripts/postcreate.jl, which I feel is not a very good path.
https://github.com/julia-vscode/julia-devcontainer/blob/60c2852703d5f4e2fc419198a95c49be37d12ccb/Dockerfile#L33

It would be great if the recommended paths were mentioned in the documentation.

[joshspicer]

Is there a recommended path for scripts to be placed in containers at this time?

Given that any base image can be used with Features, I don't think our guidance on where to place scripts would be too meaningful. Functionally the script needs to be readable and executable by the remoteUser

Looking at https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard, somewhere like /usr/share/devcontainer/feature might be a natural spot. In the first cut of this feature I was thinking of persisting the entire Feature source in that folder, and may use that (or similar) in the future if there's a reason to move from /tmp.

[eitsupi]

Thanks for the reply.
If so I might choose /usr/local/bin/ as well as /usr/local/bin/devcontainer-info for now.

[bamurtaugh]

Assigning to May for docs updates on containers.dev.

[joshspicer]

Changes have been accepted into the specification and a PR has been published with these changes for containers.dev.