Improve BuildXConfiguration isBuildX method

[rohanKanojia]

We had modified BuildXConfiguration's isBuildX method in #1799 but as per #1799 (comment) there might be more use cases for which we need to enable buildkit.

Originally posted by @rohanKanojia in #1799 (comment)

[Kytech]

Here's some context I have as to other use cases for BuildKit/BuildX outside the current use cases directly supported by this plugin:

I recently encountered another use case for RUN --mount outside of mounting secrets. I needed to run a bootstrap process in the container, but the bootstrap executable needs to be excluded from any build layers (in this case, it was to keep the final image size down, since COPY-ing it in first would result in a layer that included the bootstrap executable being pushed and stored in the registry, though there are likely other use cases). To accomplish this, the RUN step for the bootstrap executable used a RUN --mount=type=bind instruction in the Dockerfile to temporarily expose the executable during just that run step. Building a Dockerfile using these features with a docker build command directly succeeds, but building the exact same Dockerfile using this plugin fails.

Current Behavior of Plugin

Building a Dockerfile using RUN --mount=type=bind and this maven plugin resulted in the same the --mount option requires BuildKit error as observed in the secrets use case (discussed in the linked PR comments above). Since I don't have a need for using the secrets mount feature, I had to work around this by adding something to the <platforms> configuration in the <buildx> config, which is a bit unintuitive, since I don't have a need for configuring multi-platform builds through this plugin. A similar workaround would also be needed if someone had a use case for statements such as COPY --chmod, as it is also reliant on BuildKit/BuildX. Additionally, BuildKit greatly improves speed for multi-stage builds, so it is desirable to enable BuildKit/BuildX when using these builds.

Issues with Current Workaround

COPY --chmod or adding a bind mount in a Dockerfile RUN statement does not require adding corresponding parameters to the docker build command when using docker build on the CLI, unlike the secrets use case, so needing to configure <platforms>, which is used for multi-architecture builds, feels very unexpected, and doesn't seem like the ideal method to enable BuildKit if you don't need multi-platform builds. This method of enabling BuildKit would probably not be feasible for people who use the docker:push task to push to a registry used for deployment, since it could result in building and pushing more platform builds than might be needed. (e.x. push task is for a registry used for deployment to only x64 servers, or a registry that may not be configured for multi-architecture images, but arm64 is also specified in platforms so that local builds on ARM workstations would succeed. With this setup, a docker:push would build both platforms, which could greatly increase build times and build resource consumption if the other platforms would require emulation.)

Thoughts on a Fix

Issue #1267 seemed to originally request a way to just explicitly enable BuildKit/BuildX in the plugin configuration, but it was closed when just the multi-platform build feature was implemented, without addressing other use cases, such as those mentioned here, or elsewhere in that issue. It seems there are two relatively straightforward ways this option could be implemented: Using the docker REST API query parameter that someone recently mentioned in a new comment added after #1267 was closed (Comment Link), or allowing the existing BuildX builder that calls out to the CLI to be used without specifying any <platforms> (since the --platform flag passed to the CLI by this plugin could just be omitted if no platforms are specified).

It might also be worth considering enabling BuildKit by default, to mirror the Docker CLI's current behavior, while providing an option to revert back to the old classic builder for those who need it, considering that Docker has deprecated the classic builder.

[Kytech]

I found another workaround that is a bit less problematic, while looking to be reliable enough for now, to enable BuildKit in this plugin by setting an unused dummy secret from a non-existent env variable using the <secret> config option in the <buildx> config. I picked an env variable that wouldn't hold anything sensitive (ex. I just used DOCKER_BUILDKIT with the <buildx> config below)

<buildx>
  <!-- There's no current way to just enable BuildKit with a simple option in the docker-maven-plugin config -->
  <!-- We can force the use of buildx/BuildKit by configuring one of the buildx-only docker features exposed by the plugin -->
  <secret>
    <envs>
      <!-- Setting a dummy build secret that is never used. Using DOCKER_BUILDKIT env var since it doesn't carry sensitive info -->
      <emptysecret>DOCKER_BUILDKIT</emptysecret>
    </envs>
  </secret>
</buildx>

Even though the docs for this plugin indicate that <platforms> must be specified for buildx to be used, this is actually incorrect. You can specify only <secret> and buildx will still be used. It seems the documentation needs to be updated to reflect the current behavior of isBuildX.