Is build caching available for devcontainer features?

[aaronsteers]

Select Topic Area

Product Feedback

Body

I would like to rely on devcontainer "features" as a low-code, portable, and easily maintainable way to bring common capabilities to a variety of repos.

However, it appears in my experience that the features' installation process is not cached, meaning rebuilding the container takes a lot longer versus if I hard-code all of the installations into my Dockerfile using legacy/traditional installation methods. This code is much less portable, more prone to bugs, and harder to maintain vs the feature-driven equivalent.

Is it expected that I would not see caching in this layer when using features? Is there some hybrid alternative, such as 'installing' those features via Dockerfile CLI commands, but still using the code from the feature?

Related: should I expect that Prebuilds feature would include features' installations if enabled?

[samruddhikhandale]

Hi 👋

We are expecting that the Features are cached, however, there is a regression. There's a PR to fix this in review --> devcontainers/cli#382

This should get fixed soon! 😄

Related: should I expect that Prebuilds feature would include features' installations if enabled?

Are you referring to Codespaces prebuilt? If so, then yes.

[aaronsteers]

Hi 👋

We are expecting that the Features are cached, however, there is a regression. There's a PR to fix this in review --> devcontainers/cli#382

This should get fixed soon! 😄

Related: should I expect that Prebuilds feature would include features' installations if enabled?

Are you referring to Codespaces prebuilt? If so, then yes.

Fantastic. I will watch those issues.

Once those resolve, is this a good summary of expected behavior?:

1. Each feature may have an initial build+attach cost per associated Codespace, but subsequent rebuilds on the Codespace's devcontainer will use the cache.
2. The first-time build of a devcontainer using a newly initialized Codespace would pay the full cost of build on all layers (but would cache the outputs for faster next-run).
3. If enabled at the repo level, Codespace prebuilds will reuse feature layers and/or the base image caches when eligible caches exist.

Does this sound about right? And if yes on the third point, can you provide any detail on how much upstream can change before a feature's layer cache becomes unusable? For instance, assuming the feature definition itself does not change, will a feature layer cache still be eligible if a preceeding feature definition changes? And/or if the base image changes?

Again - thanks a ton.

[craiglpeters]

Codespaces Prebuilds are a snapshot of the VM once the codespace has been created (which includes the Features), so. any codespace started from the prebuild will already have the Feature layer(s) loaded. Any upstream change to a Feature will only be reflected in the newly created codespace after Prebuild has been triggered.

[samruddhikhandale]

Unfortunately, I don't have detailed knowledge on how billing works for Codespaces in a such a depth to answer your questions. Would you mind asking them in https://github.com/orgs/community/discussions/categories/codespaces ? Thanks!

[ThePlenkov]

@samruddhikhandale i dont' think is relevant to codespaces - same problem appears also when using features in a local environment on PC. While Dockerfile is cached. Features are always reinstalled..

[PRO-2684]

I've only added a remoteUser line in my devcontainer.json, and it builds my selected features again without cache. Is this intended?

devcontainer.json after modification

// For format details, see https://aka.ms/devcontainer.json. For config options, see the
// README at: https://github.com/devcontainers/templates/tree/main/src/docker-existing-dockerfile
{
        "name": "Existing Dockerfile",
        "build": {
                // Sets the run context to one level up instead of the .devcontainer folder.
                "context": "..",
                // Update the 'dockerFile' property if you aren't using the standard 'Dockerfile' filename.
                "dockerfile": "Dockerfile"
        },
        "runArgs": [
                // Enable GPU support & limit to 2 GPUs
                "--gpus",
                "2"
        ],
        "features": {
                "ghcr.io/devcontainers/features/common-utils:2": {
                        "installZsh": true,
                        "configureZshAsDefaultShell": true,
                        "installOhMyZsh": true,
                        "installOhMyZshConfig": true,
                        "upgradePackages": true,
                        "username": "automatic",
                        "userUid": "automatic",
                        "userGid": "automatic"
                }
        },

        // Features to add to the dev container. More info: https://containers.dev/features.
        // "features": {},

        // Use 'forwardPorts' to make a list of ports inside the container available locally.
        // "forwardPorts": [],

        // Uncomment the next line to run commands after the container is created.
        // "postCreateCommand": "cat /etc/os-release",

        // Configure tool-specific properties.
        // "customizations": {},

        // Uncomment to connect as an existing user other than the container default. More info: https://aka.ms/dev-containers-non-root.
        "remoteUser": "vscode" // <- Added this line
}

[ThePlenkov]

I can only assume. changing cofiguratuon file changes generated by devcontainer Dockerfile ( most likely adding USER ). The problem is - changing anything which is affecting the image always means features reinstallation.. I would like to be able to create such features that inject the generated dockerfile ( basically part of devcontainer image build ), but do dot not run as post-create script. by doing we could reuse native docker caching and not reinvent the wheel..