Suppress some nodes?

[mikepurvis]

First, what a lovely tool! Exactly what I was looking for to help communicate to my colleagues what my new and seemingly much more complicated Dockerfile is doing.

I'm wondering if it might make sense to have a command line arg that allows specific nodes on the graph to be suppressed? I have a "logs" stage that collects various output files from all over my build, and the dockerfilegraph layout looks much clearer when that is removed.

It might also make sense to automatically suppress the scratch container. Unlike with a "real" base, multiple stages that independently start from scratch are unlikely to actually have anything to do with each other, so I feel like there could be a special case to hide scratch. Alternatively, each instance of scratch could get its own node, so that scratch -> src, scratch -> logs, scratch -> conf still clearly show where they originate from but they're not coupled visually or in terms of layout.

[patrickhoefler]

Hey Mike, thanks so much for the kind words!

I’ve just released v0.19.0, which adds a new --scratch flag to give you more control over how FROM scratch stages are displayed. There are now three modes to choose from:

• collapsed (default): All scratch stages are shown as a single shared node, just like before.
• separated: Each scratch stage appears as its own separate node.
• hidden: All scratch stages are left out entirely.

This feels like a good fit since FROM scratch is basically a no-op in modern Dockerfiles, and separating or hiding those nodes can really help simplify the graph.

About the idea of hiding arbitrary nodes (like your "logs" stage): I’m not totally sure about this yet. It raises some questions — like how users would specify which nodes to hide, and whether doing so might make the graph less representative of the actual Dockerfile. For now, I think the --scratch flag solves a common case, but I’m definitely open to hearing more about your use case if you have ideas for how this could work.

Once again though, thanks for the feedback!

[mikepurvis]

Amazing, thanks for the prompt service! Result looks great for me.

Another way to think about hiding might be to think of the visualization in terms of specific targets. So rather than visualize the whole dockerfile minus X and Y "hidden" stages, instead visualize the path to get to Q and Z targets and elide anything that isn't in that path.

I do think it could still be useful to have other nodes able to adopt the "separated" model— common inputs would be a good fit for this, as would stages that collect outputs, logs, test results, etc. A possibly helpful analogue is ground planes and voltage rails on a circuit diagram.

[patrickhoefler]

I really like both of these ideas! Could you create two separate issues for them—one for the target-based filtering and one for the "separated" model for arbitrary nodes? That way we can keep the discussions focused. We can then close this one and continue the conversation in the new issues.