To build a job image, Racetrack does it in two steps with 2 different files which seems to be convoluted. That's because 2 docker build steps have different Docker build contexts:
base image, built from base.Dockerfile provided by job type plugin. Plugin directory is a build context in this step to provide the source code of a job type wrapper into the image.
job template, built from job-template.Dockerfile and a manifest (that allows to parametrize it with user-defined configuration). User's job directory is a build context in this case to provide the source code of a job to the image.
Recently, docker introduced Multiple build contexts (see Additional build contexts) that allows to simplify this process and merge it into one Dockerfile, providing 2 build context to one building process.
That would also make the building process more flexible. For instance, allowing to:
choose the base image (Python or Debian version) by job's manifest configuration. Right now it's not possible to parametrize base image with a user's manifest.
decide whether to include some files coming from a job type plugin by configuring a variable in a user's manifest.
To build a job image, Racetrack does it in two steps with 2 different files which seems to be convoluted. That's because 2 docker build steps have different Docker build contexts:
base.Dockerfile
provided by job type plugin. Plugin directory is a build context in this step to provide the source code of a job type wrapper into the image.job-template.Dockerfile
and a manifest (that allows to parametrize it with user-defined configuration). User's job directory is a build context in this case to provide the source code of a job to the image.Recently, docker introduced Multiple build contexts (see Additional build contexts) that allows to simplify this process and merge it into one Dockerfile, providing 2 build context to one building process.
That would also make the building process more flexible. For instance, allowing to: