How you push images to your registry during the build process is your choice. You might start by tagging every image with the build number and pushing all image versions to the registry as part of the CI build. Projects using efficient Dockerfiles will have minimal differences between builds, so you benefit from cached layers, and the amount of storage you use in your registry shouldn't be excessive.

If you have larger projects with a lot of development churn and a shorter release cadence, the storage requirements could grow out of hand. You might move to a scheduled push, tagging images daily and pushing the latest build to the registry. Or, if you have a pipeline with a manual quality gate, the final release stage could push to the registry, so the only images you store are valid release candidates.

For my sample CI job, I'll push to the local registry with every successful build once the tests have passed, using the Jenkins build number as the image tag. The build step to tag and push images is another PowerShell script that uses the BUILD_TAG environment variable from Jenkins for tagging:

$images = 'ch10-nerd-dinner-db:2e',
          'ch10-nerd-dinner-index-handler:2e', 
          'ch10-nerd-dinner-save-handler:2e', 
          ...

foreach ($image in $images) {
   $sourceTag = "dockeronwindows/$image"
   $targetTag = "registry:5000/dockeronwindows/$image-$($env:BUILD_TAG)"

   docker image tag $sourceTag $targetTag
   docker image push $targetTag
} 

This script uses  a simple loop to apply a new tag to all the built images. The new tag includes my local registry domain, registry:5000, and adds the Jenkins build tag as a suffix so that I can easily identify which build the image came from. Then, it pushes all the images to the local registry—again, this is running in a container in the same Docker network as the Jenkins container, so it's accessible by the container name registry.

After a few builds have completed, I can make a REST call to the registry API from my development laptop to query the tags for the dockeronwindows/nerd-dinner-index-handler repository. The API will give me a list of all the tags for my message handler application image so that I can verify that they've been pushed by Jenkins with the correct tags:

> Invoke-RestMethod http://registry:5000/v2/dockeronwindows/ch10-nerd-dinner-index-handler/tags/list |
>> Select tags

tags
----
{2e-jenkins-docker-on-windows-ch10-nerd-dinner-20,
 2e-jenkins-docker-on-windows-ch10-nerd-dinner-21,
 2e-jenkins-docker-on-windows-ch10-nerd-dinner-22}

The Jenkins build tag gives me the complete path to the job that created the images. I could also use the GIT_COMMIT environment variable that Jenkins provides to tag images with the commit ID. This makes for a much shorter tag, but the Jenkins build tags include the incrementing build number, so I can always find the latest version by ordering the tags. The Jenkins web UI shows the Git commit ID for each build, so it's easy to track back from the job number to the exact source revision.

The CI part of the build is now done. For every new push to the Git server, Jenkins will compile, deploy, and test the application, and then push good images to the local registry. The next part is deploying the solution to the public environment.