Git-Branch builds with snapshot dependencies and docker images
Hi,
we are using docker for our application. Frontend and backend are running in two different docker images. The codebase is in a git monorepo, where we have a frontend- and backend-folder.
For each image (frontend, backend) we have a TC config, that builds the image and pushes it to our container registry ('Frontend-Image', ‘Backend-Image’).
Those configs are snapshot-dependencies in a config, that deployes the application ('Deploy-Application').
Now I want to deploy our application for a specific git-branch (e.g. ‘my-feat’), where I only have changes in the Frontend.
TC will now build the Frontend-Image for the right branch. But the Backend-Image will not be build for this branch, instead it uses the main branch. Probably the VCS-Root will check, that there are no changes, but I need the build to run, because I need the correctly tagged docker-images for my branch-Version.
We tried changing the snapshot dependency to “always run new build”. This works, but is too much overhead. How can I get TC to run the Backend-Image config, even if there are no changes in the VCS-Root?
Thanks in advance,
Christian
Please sign in to leave a comment.
Hi Christian,
The 'backend' build config tries to find a suitable build on the same branch. Suppose the build on the selected revision is unavailable on the same branch. In that case, TC checks for builds on the default branch on the same revision since feature branches are usually based on the default branch. TeamCity calculates changes in feature branches against the default branch; see this article.
I can think of two workarounds in your case. You have already discovered the first workaround, which is to use the ‘always run a new build’ option in the dependency settings. The downside is that you will have some number of unnecessary builds.
The second approach is to create a duplicate of the the entire build chain. The ‘first’ build chain would only run for the default branch, assuming that you need builds on the default branch. The ‘second’ build chain will only target ‘feature’ branches. For this chain, you can explicitly exclude the default branch via the build configurations' Branch Filters. This should prevent TeamCity from starting builds on the Default branch, so when it can't find a suitable build in the corresponding feature branch, it should start one there instead of attempting to select one from the Default branch. The downside of this approach is having to split the singular build chain in two.
Alternatively, you can also alter the way you tag the corresponding docker images. Here, you also have several options. First, you can have a special build configuration parameter from which you get the label name to apply to the images. To make sure the label name is always correct, you can get it from up the build chain from the ‘Deploy’ build configuration using the
reverse.dep.*parameters; see this article. The downside of this approach is that you won't be able to properly utilize the build re-use functionality properly, because builds with customized parameters (including those customized via thereverse.dep.*parameters).You can also create a separate build step (or even a separate build configuration) that tags the backend and frontend images with desired branch-specific tags. The built images could then have both master and branch tags, but there wouldn’t be a need to re-build them when the branch changed.