Are there any best practices or patterns that advise building your docker image, rather than just your project, during your CI build step?
I have a GitLab CI pipeline with these steps:
- build (builds the dotnet solution with
dotnet build) - test (runs the unit tests with
dotnet test) - package (builds the docker image with a Dockerfile that builds the solution with
dotnet publishthen copies the output to the final image, and pushes the image to the registry) - deploy (deploys the docker image from the registry to the environment)
This all works fine, but it occurs to me that if the package and publish steps only happen on master , then you would only know about a problem with docker build once branches are merged.
Should the build step (and the test step???) use the docker build rather than an independent build of the project, therefore ensuring that “the whole thing builds” rather than just “the dotnet solution” builds? I chose the latter initially, as it seemed to be the simplest way to fail early, for the fewest possible reasons, but now I’m not so sure this is optimal.
2
Answers
On the pipeline for a Merge Request you could build a docker image from there as well to see if it works. Just keep the option in GitLab to force that the Merge Request should be rebased before it passes. There is a lot of strategies depending on multiple things. So it’s hard to say best practices.
A simple pipeline example of a Merge Request:
But try to rebase before pushing if there are any conflicts that are easier to solve locally.
Building docker image as part of the Merge Request pipeline (before merging to
main) is a great way to shift left because you test the buildability of a containerized app before merging to the default branch while without it, the main branch will contain unusable source code if the image can’t be built from it…