I have created a multi-stage build pipeline for Azure DevOps that pushes a built image to Docker Hub. I am now trying to set up a release pipeline that will use that image as its build artifact. I have set all of that up using my configured service connection, and the Azure build pipeline runs successfully to completion, but I don't know how to then refer back to the artifact when I use e.g. kubectl to push that image into my Kubernetes cluster.
2 Answers
what mostly we are doing like we have this push step at the last of the multi-stage build. (we have also the same step to tag image to clear confusion)
- id: 'push the docker image to registry'
name: 'gcr.io/cloud-builders/docker'
args: ['push', 'gcr.io/$PROJECT_ID/$REPO_NAME/$BRANCH_NAME:$SHORT_SHA']
we are using the GCR currently.
so when the build gets pushed to the registry it will create a formation URI-based auto variables getting set into the CI/CD.
same way in the release CI/CD trigger we have step to push the image to the Kubernetes cluster along with the environment variables.
- id: 'set docker image URI in YAML file'
name: 'ubuntu'
args: ['bash','-c','sed -i "s,DOCKER_IMAGE_NAME,gcr.io/$PROJECT_ID/$REPO_NAME/$BRANCH_NAME:$SHORT_SHA," deployment.yaml']
it replaces the YAML file values with the URI of the docker image where everything comes from the env variables and creates a formation of the docker image path. at last whole deployment.yaml file get to apply to the Kubernetes cluster.
incase if you want to hotfix or deploy with something special commit hash in that case you can overwrite the SHORT_SHA
value by setting up the values to CI/CD trigger and run it.
So your build trigger will continuously building and pushing the images to the registry and whenever you want to deploy you can run the release trigger by default it will take the latest commit hash from the Git and set it to environment variables.

- 27,020
- 6
- 48
- 102
-
1Many thanks for your input Harsh, unfortunately the problem was more user error than anything. Using the right image tag is key, though, as you point out. – David Keaveny Apr 28 '21 at 07:57
The issue was primarily that I was using the build
command on the Docker step, rather than buildAndPush
, so while the image was being created and tagged, it wasn't being pushed to the repository. As soon as I fixed that, the release pipeline correctly checks for images created by the just-run build pipeline as artefacts; I just make sure that the release pipeline uses the build number for the release number, then it's child's play to retrieve the image with the same tag.
As happen too often, problem exists between keyboard and chair. Looking at it again with fresh eyes and clear mind, and trying to explain the issue to co-workers, made the problem jump out of the screen at me.

- 3,904
- 2
- 38
- 52