Add support for arbitrary CLI build commands to be passed through to the CLI builder.

[zoonage]

What this PR does / why we need it: Add support for arbitrary CLI build commands to be passed through to the CLI builder.

Which issue(s) this PR fixes: docker/compose#7997

Fixes docker/compose#7997

[EricHripko]

Hi @zoonage - thank you for putting this contribution together 👍 It looks like you're aiming to enable SSH secrets, which is being discussed under #81. Do you think that your request will be satisfied by the linked issue?

[zoonage]

Hi @zoonage - thank you for putting this contribution together 👍 It looks like you're aiming to enable SSH secrets, which is being discussed under #81. Do you think that your request will be satisfied by the linked issue?

It's turned into more of a "allow arbitrary CLI arguments to be passed through" than something specifically focussed on mounting the SSH agent into the container now

[EricHripko]

cc @kohidave too

[EricHripko]

Given that we're trying to keep the Compose spec somewhat agnostic of the implementation, I'm concerned about the portability of this addition as it'd essentially lock the Compose file into a single CLI implementation. Would welcome hear thoughts from other maintainers on this though 👀

[zoonage]

Given that we're trying to keep the Compose spec somewhat agnostic of the implementation, I'm concerned about the portability of this addition as it'd essentially lock the Compose file into a single CLI implementation. Would welcome hear thoughts from other maintainers on this though 👀

My thinking behing this is that it's hard to strike a balance between being agnostic and having support for new features in Docker as soon as they come out (especially after BuildKit released quite a few things at once).

That said I can change this to specify ssh, secret mounts, and anything else based on what is decided, either way is going to be pretty much the same amount of effort

[ndeloof]

My :-1 on this. Passing arbitrary command obviously would locally unlock features but would make it impossible to adapt to another build context.

Let's imaging we want to provide support for Google Cloud Build. If the build require ssh keys, then it's highly probable they don't just expose buildx command line flags, but offer another way to setup credentials. With adequate abstraction, we can adapt to the infrastructure.

As a Jenkins contributor I had to fight many times with the lack of abstraction around withDocker which basically expose the CLI flags, and make it impossible to adopt an alternate approach.

I'm convince we should not hurry here, and just adopt the buildkit features with adequate declarative abstraction. In the meantime, just a reminder we support x- extensions if you want to experiment a syntax to introduce ssh support in docker-compose.

[ndeloof]

:-1 as explained on #145 (comment)

would better first open an issue on the spec to debate this
also need to update the specification docs if a new field is introduced

[zoonage]

:-1 as explained on #145 (comment)

would better first open an issue on the spec to debate this
also need to update the specification docs if a new field is introduced

Created #157 for discussion, should I leave this PR open for updating after the discussion or close it and open a new one later?

[ndeloof]

can be kept open, let's wait for decisions on #157

[zoonage]

Closing this out as I don't have capacity to make any progress on this and haven't for a while