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.
Changelog
Changed
Job type plugins can now build job images from a single Dockerfile.
Base Dockerfile has been merged with a job template.
It gives more flexibility by allowing to parameterize
all build commands of a base image with a user-defined configuration.
See Developing plugins
and Job type plugins documents.
Old style is still supported to keep backwards compatibility.
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.Dockerfileprovided 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.Dockerfileand 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:
Changelog
Changed