Centralize implementation for `library_generation.Dockerfile` and its Airlock variant

[diegomarquezp]

We should probably have a way to share the common code between the two, or maybe only keep the airlock one if it can be used locally as well. Otherwise these two files can easily get diverged from each other as they evolve. This is a separate future enhancement though.

Originally posted by @blakeli0 in #3726 (comment)

[diegomarquezp]

Dockerfiles don't provide ways to natively reuse instructions like RUN.

I would lean towards a script using jinja2 and two JSONs containing the base image digests.

[blakeli0]

Another solution is to remove the need of two docker files. If we can download the docker image from Airlock in local, then we don't need the one that download images from docker central.

[zhumin8]

iiuc, the only difference between the 2 dockerfile is the base image? If so,

can we explore using a build argument (ARG) to specify the base image at build time. Use the airlock variant Dockerfile for default base image, like

# Default to one of your base images
ARG BASE_IMAGE=base-image
FROM ${BASE_IMAGE}

# ... other common instructions ...
RUN apt-get update && apt-get install -y ...
COPY . /app
...

We should be able to build passing a different value for BASE_IMAGE as needed:

docker build --build-arg BASE_IMAGE=xxx -t local-test:latest .

[diegomarquezp]

Thanks @zhumin8 for the pointer.

Yes, the docs say it's possible as long as the ARG is at the top of the Dockerfile

https://docs.docker.com/reference/dockerfile/#understand-how-arg-and-from-interact

[diegomarquezp]

I'll add a POC

[diegomarquezp]

@zhumin8 @blakeli0 the POC works in #3870. Thank you for the recommendation. We may want a more formal way of handling the common inputs in the GCB yamls, though.