Proposal: add new --sync-output flag to bake

[jedevc]

Potentially fixes #1089. ~~Depends on a server that includes that patch here: https://github.com/moby/buildkit/pull/2947~~

This proposal patch introduces a new syncable output option, which ensures that all builds finish simultaneously in the solver, so that no outputs are completed independently of each other. This allows bake to easily express the notion that either all builds should succeed and output or none of them should.

Usage:

$ docker buildx bake --sync-output

Comments and thoughts appreciated :tada:

[ciaranmcnulty]

Yes that's exactly what I had in mind 👍

[jedevc]

Have updated with the new Evaluate API introduced in https://github.com/moby/buildkit/pull/3137.

Still not sure about the flag name, but the functionality should be correct now (have tested with buildkit before+after the evaluate API merged to check the StatFile fallback works correctly).

[jedevc]

Adding to the v0.10 milestone, think this would be good to get in there.

Revisiting this after a while, I wonder if maybe we might want to make this the default behavior? Or some other way that doesn't involve needing to add lots more flags, IMO not needing a lot of extra flags on the cli is one of the selling points of bake :thinking:

[jedevc]

Ping @tonistiigi @crazy-max any thoughts on the overall approach here? I'm a bit hesitant around adding new flags to the CLI though :thinking:

Possible approaches:

• Just add the new flag (clutters the command line)
• Make the synced outputs default (slows down quite a few builds)
• Maybe add a sync key or similar to each group in bake, all targets part of that group would be synced? We could allow setting it at the command line using --set (though this doesn't work very well if you don't use groups, and just specify multiple targets).

[Nithos]

Does the current action support group entries currently into the targets input? If so adding a sync to a group definition is a fairly elegant solution that avoids the flags. I am assuming that the group would get decomposed and automatically parallelize the process rather than having to manually deconstruct the list of targets present within the group and run through the GH matrix.

[crazy-max]

Having a sync field for group is a good idea. Hence my suggestion to have a less opinionated flag named --sync instead of --sync-output.

I'm thinking about another use case now. Should we have a fail-fast strategy that cancels all in-progress targets in the group if any target fails? I think this is the current behavior.

[jedevc]

Yeah, if we have a sync field, having the ability to sync at different points would be good:

• fail-fast is the current behavior
• output syncs at the output stage, like this patch
• fail-slow (naming is hard) is the opposite of fail-fast, all builds are run to completion (though we might also want to have variants of this that sync at output or after).