When configuring the Docker Local Repository as follows:
Max Unique Tags: 2
Docker Tag Retention: 3
In this example, we divided the process into two distinct tags and uploaded four images under each tag, demonstrating the "overwriting" aspect relative to "Retention". It's important to note that tags are preserved only up to the maximum allowed we set in our repository configuration.
First we downloaded four Nginx images from an upstream source, each with a unique IMAGE ID and Size. Then we began to tag these images and push them to our docker-test-local repository using the same format for each, such as:
<DOCKER_IMAGE>:<DOCKER_TAG>; ex:( nginx:1.0 ).
Upon pushing our first docker image, the retention-based overwriting has not yet occurred. The SHA value for this initial image is stored under manifest.json with the tag 1.0. However, as subsequent images are pushed, overwriting begins to occur, and the effects of retention policies take place:
After completing the initial phase of uploading three images, we proceeded to push a fourth image. Since this exceeded the Tag Retention limit of 3, the oldest 'Latest' tag iteration (SHA 1)—which corresponds to the original first push—was removed.
Upon pushing the latest image, the corresponding sha256 value can now be found in the manifest.json file:
As we can see the Retention will stay less than or equal to 3
Docker Tag Retention - By default, pushing a docker image to an Artifactory with an identical name:tag as an existing image in that Docker repository will result in the older image being overwritten. By increasing the Docker Tag Retention value, you can preserve multiple versions of the same image:tag within the same repository. In this setup, the most recently pushed image retains the original tag, while older images are tagged with their digest SHA value. This allows for better version management and traceability within your Docker repository.
Max Unique Tags: 2
Docker Tag Retention: 3
In this example, we divided the process into two distinct tags and uploaded four images under each tag, demonstrating the "overwriting" aspect relative to "Retention". It's important to note that tags are preserved only up to the maximum allowed we set in our repository configuration.
First we downloaded four Nginx images from an upstream source, each with a unique IMAGE ID and Size. Then we began to tag these images and push them to our docker-test-local repository using the same format for each, such as:
<DOCKER_IMAGE>:<DOCKER_TAG>; ex:( nginx:1.0 ).
Upon pushing our first docker image, the retention-based overwriting has not yet occurred. The SHA value for this initial image is stored under manifest.json with the tag 1.0. However, as subsequent images are pushed, overwriting begins to occur, and the effects of retention policies take place:
After completing the initial phase of uploading three images, we proceeded to push a fourth image. Since this exceeded the Tag Retention limit of 3, the oldest 'Latest' tag iteration (SHA 1)—which corresponds to the original first push—was removed.
Upon pushing the latest image, the corresponding sha256 value can now be found in the manifest.json file:
As we can see the Retention will stay less than or equal to 3
Docker Tag Retention - By default, pushing a docker image to an Artifactory with an identical name:tag as an existing image in that Docker repository will result in the older image being overwritten. By increasing the Docker Tag Retention value, you can preserve multiple versions of the same image:tag within the same repository. In this setup, the most recently pushed image retains the original tag, while older images are tagged with their digest SHA value. This allows for better version management and traceability within your Docker repository.