You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because the container configuration is cached in the container labels after creation, any changes to the local config file are ignored for future operations on the container.
In the case of the lifecycle scripts (onCreateCommand, postCreateCommand, ...) it would be useful in cases of pooling container if changes to the config would be honored so that the container doesn't need to be recreated.
For example, if a container is created with an empty configuration for a pool, then we should be able to later change the configuration to and re-apply the post-creation lifecycle logic against the existing container.
{
"postCreateCommand": "touch foo"
}
It would also be useful if the cli could detect the case of a configuration collision and fail with a reasonable message. For example, if the container is created with a postCreateCommand already and then the value is changed, then this re-application logic should fail.
The text was updated successfully, but these errors were encountered:
For example, if a container is created with an empty configuration for a pool
Important to call out here that there's never a container created via an "empty configuration" (that's more a Codespace user-concept, but behind the scenes there's always a config)
+1 I think this is a nice optimization, either automatically or via a new CLI command codespaces could invoke (like devcontainers update ... or devcontainers reconcile or devcontainers rebuild).
As a couple folks discussed offline, this could drastically shorten the "rebuild" flow by re-applying configuration that doesn't need a full container rebuild. Think of it as an "incremental" rebuild that doesn't ever delete the container or take you out of the editor experience (for changes that do not require a rebuild, like adding a postStartCommand)
That would add the config on top of the existing metadata on the container (which is readonly). We also use this codepath when we locally attach to a container that was started by the user using the Docker CLI and the image comes with dev container metadata. The merging is the same codepath as when you regularly start a dev container.
Because the container configuration is cached in the container labels after creation, any changes to the local config file are ignored for future operations on the container.
In the case of the lifecycle scripts (
onCreateCommand
,postCreateCommand
, ...) it would be useful in cases of pooling container if changes to the config would be honored so that the container doesn't need to be recreated.For example, if a container is created with an empty configuration for a pool, then we should be able to later change the configuration to and re-apply the post-creation lifecycle logic against the existing container.
It would also be useful if the cli could detect the case of a configuration collision and fail with a reasonable message. For example, if the container is created with a
postCreateCommand
already and then the value is changed, then this re-application logic should fail.The text was updated successfully, but these errors were encountered: