Given a repository containing a Dockerfile
that defines the build environment used by the CI pipeline as well as by the developer (e.g. as a Visual Studio Code devcontainer), the CI pipeline shall fulfill the following requirements:
Dockerfile
present in the working branch (or the result of its merge to the target branch where applicable in the context of a pull request).Dockerfile
shall be considered automatically without the need for manual user intervention (i.e. local docker build followed by a manual push).Dockerfile
has already been "baked" into such an image pushed to the registry.I couldn't find an existing best practice to implement that out of the box (my CI environment being Azure DevOps Pipelines if it matters) so I came with the following concept:
Dockerfile
's hash.docker_image_name:$hash
from the docker registry.docker_image_name:$hash
from the Dockerfile
and push it to the docker registry.docker_image_name:$hash
(from the registry / from the local cache) to run the CI pipeline (using Azure's container jobs in my case).Questions:
I wasn't exactly sure if you was asking how to use a vscode dev container in a azure pipeline or if you was asking how to replicate that dev container functionality from scratch.
@Levi: My mentioning vscode's devcontainers might have been misleading since it was just part of the context, but not part of the actual question. The question was specifically about how to use the very docker image specified by the currently valid Dockerfile
without building the image on each and every commit.
I think the question boils down to "How do I avoid rebuilding my container image in CICD" which probably has been asked and answered before. I went ahead and gave a new answer though.