Run onCreateCommand and updateContentCommand in prebuilt images (not pre-built Codespaces)

[andreiborisov]

Codespaces has an option to bake onCreateCommand and updateContentCommand steps into the image in case they are time-consuming.

If a user installs dependencies into a dev container via new features spec, they won't be able to reference those in the image's Dockerfile because features are applied after the initial build process. So the only way to customize the image becomes those aforementioned steps.

Providing a way to create an analog of Codespaces prebuilds would allow the publication of organization-wide fully ready-made images for local use.

[chrmarti]

Interesting idea. (Codespaces are not including those commands in the image, but run them to warm-up a VM.)

[metaskills]

DARN! I was about to do a test using onCreateCommand to make our Codespaces prebuilds better by installing package dependencies ahead of time for the developers. Using a hack mentioned here (devcontainers/spec#85 (comment)) but if these are not being run by the CLI because the spec (devcontainers/spec#60) has yet to support it... I'm out of luck for now.

I'm so excited by internal features and prebuilds together. Please help me make things easy for our DX teams.

[Chuxel]

@metaskills To be clear, devcontainers/spec#60 adds support for Dev Container Features to trigger lifecyle events when the container is created. That allows you to use Features with "pre-built Codespaces" to do this kind of thing just like you can now by just adding that property into devcontainer.json.

So - you can do this without Features in pre-built Codespaces today... its just not quite as reusable.

But, in all cases, the lifecycle hooks are executed when a container is created (not the image). Pre-built Codespaces are cached fully created containers and source code volumes so, the container already exists. This is raising a broader consideration of some variant of pre-built codespaces that would work locally... which implies some new way of archiving contents or putting everything in the image.

@metaskills @andreiborisov Note that devcontainer.json data is in fact stored on the image when you pre-build an image (not a codespace) using the dev container CLI. It won't execute it and store it in the image, but just referencing the image would trigger those events when the container was created. This landed in the last month (its #188), so it's quite new.

[metaskills]

But, in all cases, the lifecycle hooks are executed when a container is created (not the image).

✅ That was very helpful. Of course 🤦‍♂️ it works that way. I might have to re-consider some of the optimizations I was looking for in diff ways outside of lifecycle hooks.