Allow adding arbitrary buildkit config

Params like `REGISTRY_MIRRORS` don't really scale well to cover
a complex schema like buildkit's toml configuration. Plus, they
can become out-of-date.

A param whose content is written verbatim to the config file
allows defining everything the configuration has to offer, now
and in the future. It also avoids having to add new params one by
one as users request the ability to configure individual values.

Closes: #120

README.md

@@ -157,6 +157,9 @@ _(As a convention in the list below, all task parameters are specified with a
   (`,`) list of key-value pairs (using syntax `hostname=ip-address`), each
   defining an IP address for resolving some custom hostname.
 
+* `$BUILDKIT_EXTRA_CONFIG` (default empty): a string written verbatim to builkit's
+  TOML config file. See [buildkitd.toml](https://docs.docker.com/build/buildkit/toml-configuration/).
+
 > Note: this is the main pain point with reusable tasks - env vars are kind of
 > an awkward way to configure a task. Once the RFC lands these will turn into a
 > JSON structure similar to configuring `params` on a resource, and task params

buildkitd.go

@@ -173,6 +173,13 @@ func generateConfig(req Request, configPath string) error {
 		return err
 	}
 
+	if len(req.Config.BuildkitExtraConfig) > 0 {
+		_, err = f.WriteString(req.Config.BuildkitExtraConfig)
+		if err != nil {
+			return err
+		}
+	}
+
 	return f.Close()
 }
 

types.go

@@ -64,6 +64,8 @@ type Config struct {
 
 	BuildkitSecrets map[string]string `json:"buildkit_secrets" envconfig:"optional"`
 
+	BuildkitExtraConfig string `json:"buildkit_extra_config" envconfig:"BUILDKIT_EXTRA_CONFIG,optional"`
+
 	// Unpack the OCI image into Concourse's rootfs/ + metadata.json image scheme.
 	//
 	// Theoretically this would go away if/when we standardize on OCI.