Accessing build-options after shrinkwrap for separate builders

When using the shrinkwrap option to generate a build context for separate builders like buildkit, kaniko or else, we copy all information about the build (Files + Dockerfile) to the ./build directory. However, for a successful build we also need the build-args and build-options which are fed into the docker build process (or in our case the kaniko process).

In our case, we use kaniko to build the function images inside our Kubernetes cluster with one-off-jobs. Our images need some additional packages installed, so we use the build options feature of our templates. The kaniko-job is very similar to the one @alexellis created for his blogpost. The problem is that we wont populate the ADDITIONAL_PACKAGES arg in the Dockerfile and thus the build fails.

So a local workaround would be to parse the template.yml and stack.yml ourselves, identify which function is being built currently and which options apply and then construct the build args. However this would be a lot of duplicated effort, as faas-cli already has this information.

A good idea would be to settle on a way to exchange that information with the builder, maybe adding it to a specific file in the build context?

Expected Behaviour

It should be possible to save the relevant build args for the current build during a shrinkwrap. This might take the form (to be discussed) of a file containing all build args as key-values:

ADDITIONAL_PACKAGES="gcc"

Current Behaviour

During a shrinkwrap build only the files of a build context are copied. The build args are missing and thus cannot be restored for an external builder.

Possible Solution

See Expected Behaviour.

Context

We build function images via kaniko similar to the way @alexellis did it for his blogpost. There build options are sadly not usable with the builds.

Your Environment

• FaaS-CLI version ( Full output from: faas-cli version ):

$ faas version
  ___                   _____           ____
 / _ \ _ __   ___ _ __ |  ___|_ _  __ _/ ___|
| | | | '_ \ / _ \ '_ \| |_ / _` |/ _` \___ \
| |_| | |_) |  __/ | | |  _| (_| | (_| |___) |
 \___/| .__/ \___|_| |_|_|  \__,_|\__,_|____/
      |_|

CLI:
 commit:  f7c29ea19b5df9d7aa87e9c70aacf4d9315da2cd
 version: 0.12.4

Gateway
 uri:     http://localhost:9645
 version: 0.18.17
 sha:     18f6c720b50db7da5f9c410f9fd3369ed7aff379
 commit:  Extract a caching function_query type


Provider
 name:          faas-netes
 orchestration: kubernetes
 version:       0.10.5
 sha:           9be50543b372381a505e9e54a1356bb076c8f01f

• Docker version: 19.03.8

• Are you using Docker Swarm (FaaS-swarm ) or Kubernetes (FaaS-netes)?
  FaaS-netes

• Operating System and version (e.g. Linux, Windows, MacOS):
  Ubuntu and Windows 10

Start by tracing the shrinkwrap command and how it copies files into the build directory, then inspect how template.yml and stack.yml build args and options are resolved. Define how that metadata should be stored in the generated context for kaniko or another external builder, and verify that the current build args can be recovered without re-parsing the configuration.