There is a lot of complicated and redundant logic built into the many Docker files in this repo. A s result, it has become impractical to upgrade to the build process. I don't want to maintain multiple almost identical Docker files (one for each job).
Let's make the klay_beam docker image flexible enough to build a variety of different jobs on top of. We'll put the complex work into this one Dockerfile, and enable it to produce images that other jobs can reliably build on top of with Docker's FROM statement.
This mirrors the convention in the Docker ecosystem: Make many differently tagged docker images with a spectrum of different contents for things like different python versions or underlying OSes.
TLDR: Put the build complexity upstream, so we only have to manage it once.
There is a lot of complicated and redundant logic built into the many Docker files in this repo. A s result, it has become impractical to upgrade to the build process. I don't want to maintain multiple almost identical Docker files (one for each job).
Let's make the klay_beam docker image flexible enough to build a variety of different jobs on top of. We'll put the complex work into this one Dockerfile, and enable it to produce images that other jobs can reliably build on top of with Docker's
FROMstatement.This mirrors the convention in the Docker ecosystem: Make many differently tagged docker images with a spectrum of different contents for things like different python versions or underlying OSes.
TLDR: Put the build complexity upstream, so we only have to manage it once.