Proposal: Add support for Build debugging

[colinhemmings]

Problem

It can be a struggle to understand what happens during a Docker build. They lack visibility into how the build context is used, what layers are created or cached, and how the filesystem changes step-by-step, making it difficult to diagnose slow or broken builds.

• How the build context is prepared.
• How layers are created, reused, or invalidated.
• How the filesystem changes between layers.
• Whether cache hits or misses occur, and why.

Proposed Solution

Enhance the Docker DX extension to surface more detailed build debugging information, ideally integrated into the VS Code UI:

• Show how the build context is assembled (files included/excluded).
• Visualize each build layer: what files were added, modified, or deleted.
• Indicate cache hits/misses clearly at each build step.
• Expose the current working directory (WORKDIR) and filesystem state before and after a step.
• Provide build step logs with additional debugging output (optionally toggled on).

This could be surfaced through:

• A side panel view summarizing build steps and cache usage.
• Inline diagnostics in Dockerfile editors (e.g., “this line caused a cache miss”).
• Enhanced logging in the VS Code Terminal output.

[devznsh]

I completely agree with this proposal! Debugging Docker builds is currently opaque, and these features would save countless hours.

1. Cache Mysteries: It’s hard to tell why a step invalidates cache (e.g., COPY . vs COPY package.json).

2. Context Confusion: Users often accidentally include/exclude files due to unclear .dockerignore behavior.

3. Filesystem Blindness: No easy way to see how RUN or WORKDIR changes the image state.

If there’s interest from maintainers, I’d be glad to:

Test early prototypes.

Contribute to log parsing logic or UI components.

[colinhemmings]

Great feedback @devznsh. We are currently working on enhancements to the language server for Compose files, but we plan to start on this soon after.
If you are keen to contribute, we would greatly appreciate your help. What ideas did you have about UI components and log parsing? Are there specific gaps you currently see?

[devznsh]

@colinhemmings exciting to hear that this is on the roadmap !

For log parsing, a few ideas I had in mind:
• Parse output from docker build --progress=plain to extract per-step detail, especially cache usage, command execution, and file diffs.
• Expose WORKDIR, environment variables, and relevant filesystem context during each step.

Current gaps I’ve seen:
• .dockerignore behavior is a common pitfall—users often don’t realize which files are being sent.
• No visibility into how RUN, COPY, and WORKDIR cumulatively affect the image state.

[thaJeztah]

For dockerignore, there's also this ticket I created once, to link to various issues related to it;

• [epic] builder: collected issues on improving .dockerignore moby/moby#40319