I am building a common library inside a docker container. A number of applications depend on the library. They build inside the common container and the compiled files are copied in a "slim" application container.
The common library Dockerfile looks as such:
FROM common:latest
COPY sourcecode
RUN build steps for library
The reason to iterate over the latest image is to keep multiple versions of the same library in the latest image. Then the services which depend on the library can build inside latest common image and find the correct version of the library on which they depend.
Eventually, the max layer depth of docker builds is exceeded.
Complication: The common image actually contains multiple packages, each of which is versioned. All the apps that depend on the libraries are also versioned and depend of specific versions of the packages. All the builds happen automatically in a CI pipeline.
Solution 1: Don't build the common libraries in docker. Instead clone the common repository build the correct versions, build your app on top of it's dependencies and copy the artifact in an image. However, now your CI agent is building the same version of the libraries again and again.
Solution 2: Start versioning the common image. Find a way to correlate the app version with the common image tag. Pass the tag in a --build-arg to docker build. This solution is complicated. Versioning the common image is doable. For instance, the build digest can be used to tag. Now you can't correlate the app versions with the common bundle in a straight forward way.
Correlating is possible in my special case. The agreement is that functionality is only added to the common libraries, (whether this may be a terrible idea). In this case, every time the a common library is iterated, I can make a small commit in the app repositories, saving the docker common image tag and bumping some dependencies in the application source code.
Then this saved tag can serve the docker build of the applications until the next iteration of common. No matter how much any staging environment lags behind, I can use the tag that lives in the application repository branch from which the environment is deployed. This also allows patching against the tag in need of hot-fixes.
Question: How are you solving this problem? What are the common practices?
P.S. This is not hypothetical. I exceeded the max depth today. Fortunately, someone made docker-squash.
