Answers: <p>I ended up using <a href="https://github.com/goldmann/docker-squash" rel="nofollow noreferrer">docker-squash</a>.</p>
  <p>Install: <code>pip install docker-squash</code></p>
  <p>Example usage, squash up to <code>&lt;LAYER&gt;</code>:</p>
  <pre class="lang-bash prettyprint-override"><code>docker-squash -f &lt;LAYER&gt; -t &lt;IMAGE&gt;:squashed &lt;IMAGE&gt;:&lt;TAG&gt;
  </code></pre>
  
Answers: CC BY-SA 4.0
Answers: 2024-03-08T11:44:47.683Z
Answers: 2024-03-08T11:44:47.683Z
Answers: superAnnoyingUser
Body: <p>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 &quot;slim&quot; application container.</p>
  <p>The common library <code>Dockerfile</code> looks as such:</p>
  <pre><code>FROM common:latest
  COPY sourcecode
  RUN build steps for library
  </code></pre>
  <p>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.</p>
  <p>Eventually, the max layer depth of docker builds is exceeded.</p>
  <p><strong>Complication:</strong>
  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.</p>
  <p><strong>Solution 1:</strong>
  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.</p>
  <p><strong>Solution 2:</strong> Start versioning the common image. Find a way to correlate the app version with the common image tag. Pass the tag in a <code>--build-arg</code> to <code>docker build</code>. 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.</p>
  <p>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.</p>
  <p>Then this saved tag can serve the <code>docker build</code> 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.</p>
  <p><strong>Question:</strong>
  How are you solving this problem? What are the common practices?</p>
  <p><em>P.S. This is not hypothetical. I exceeded the max depth today. Fortunately, someone made <a href="https://github.com/goldmann/docker-squash" rel="nofollow noreferrer">docker-squash</a>.</em></p>
  
Tags: <docker><versioning>
Title: A case for exceeding docker's max depth
UserDisplayName: superAnnoyingUser
ThreadText: # A case for exceeding docker's max depth
  
  (Asked by: username_0 on 2022-10-25)
  
  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](https://github.com/goldmann/docker-squash).*
  
  **Tags:** docker, versioning
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2024-03-08. Score: 1 | Accepted answer
  
  I ended up using [docker-squash](https://github.com/goldmann/docker-squash).
  
  Install: `pip install docker-squash`
  
  Example usage, squash up to `<LAYER>`:
  
  ```bash
  docker-squash -f <LAYER> -t <IMAGE>:squashed <IMAGE>:<TAG>
  
  ```
  
  
  ---
  
  