feat: BuildKit Support

This change switches the build image to prefer BuildKit (docker buildx) for Dockerfile builds, although the old-style build is still usable if desired.

Fixes #10 (closed)

This change makes !66 (closed) and !53 (closed) Redundant

Motivation

1. Remote Cache: BuildKit can leverage remote caching without needing an explicit docker pull

2. Multi Stage Caching: BuildKit can cache layers from all build targets, not just the final image.

3. Maintainence: Simplier one line syntax means no external docker pull and docker push lines.

4. Future features: buildx has other cool features, that Auto Build could then take advantage of, like multi-platform builds

Behaviour and Features

The new default is to use docker buildx for docker builds. This can be disabled by explicitly setting DOCKER_BUILDKIT to an empty string.

Note If Build Secrets are required AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES is non-empty, Buildkit is always used, regardless of the value of DOCKER_BUILDKIT.

The following variables have been added:

• AUTO_DEVOPS_BUILD_CACHE - can be one of inline, registry, or blank to disable caching (Default: inline)
• AUTO_DEVOPS_BUILD_CACHE_MODE - When registry caching, this can be one of max or min. Max sets it to also cache the layers for intermediate build steps. (Default: max)
• AUTO_DEVOPS_BUILD_CACHE_REF - The reference to use when registry caching - Defaults to $CI_APPLICATION_REPOSITORY:cache

Example Project

https://gitlab.com/red-coat-development/website uses AUTO_DEVOPS_BUILD_CACHE=registry with a custom AUTO_DEVEOPS_BUILD_CACHE_REF.

Discussion and Gotchas

Registry Caching Looks Nasty in GitLab UI

As reported in gitlab-org/gitlab#335121 (closed), when using the GitLab Container Registry as the cache destination, GitLab's UI currently does not respond to this nicely, and makes it difficult to delete cache tags.

Should This Support Local Caching

I wasn't sure if it is worth supporting local caching (where BuildKit caches directly to a path that is given). In theory this could be cached between jobs using job caches... however as these are downloaded each time, registry caching seems the superior option so I left support for this out entirely.

Default Cache Ref

The default reference when registry caching is $CI_APPLICATION_REPOSITORY:cache - I'm not sure what the best / nicest practices for this are so this seemed like a sensible default.

In theory, the more shared a cache is, the better, so it may make more sense to use something like $CI_REGISTRY_IMAGE:cache to ensure cross branch caching - perhaps this is too opinionated?

Using a sub image, rather than a sub tag, ($CI_REGISTRY_IMAGE/cache:latest) may also be prefered but this may be less compatible with other registries that do not support sub images.