Now you can merge the sources of a build into a specified branch using the automatic merge build feature. It handles the case when you create a branch to fix some issue and push the branch only once when the work is complete and ready to be merged.
Those of you who use remote-runs from IDE know that the great thing about them is that IDE will submit your changes automatically once the build finishes successfully. However, as it happens with every technology, remote runs have some shortcomings.
When you start a remote run, TeamCity applies your patch on top of the latest revision at the time the build starts. So when you decide to submit your changes, the result of the personal build reflects the final state of your repository more closely, which is great! But if your colleague breaks some tests or, God forbid, a compilation while your remote run is waiting in a queue – your build will fail even though you didn’t break anything.
Another shortcoming is that in order to commit personal changes, TeamCity needs your IDE to be open so that the TeamCity plugin can make a commit on your behalf. Besides, personal builds force you to make all the changes in a single commit which is not always convenient.
With the automatic merge you get the picture similar to remote runs. When a build finishes successfully in your feature branch, the branch is merged automatically to the default.
As with every merge, the automatic merge works best with short-lived branches. The merge itself doesn’t care about the age of your branch, but the older your branch is, the higher the probability of failure due to conflicts is. Actually, not only files can be moved around, but also semantics can change over time. Things get worse when you, for example, extend some java class while your colleague removed it in the default branch. The merge succeeds but your compiler won’t be happy with the result.
Still, comparing to remote runs, the automatic merge can get you the best of 2 worlds: the isolation of feature branches and the ability to integrate your changes automatically. As a bonus, you can finally turn off your computer when you go home – the merge is performed on the server, so no open IDE is required.
First, configure feature branches. Then add the Automatic Merge build feature to your build configuration. Specify a pattern for branches to merge, e.g. ‘+:issue-*’; a destination branch, e.g. ‘master’; and a merge commit message to use. By default, the merge is performed only for green builds, but you can also choose to run a merge if no new tests failed. If there are any conflicts during a merge, TeamCity fails the build.
You can specify the merge commit author in VCS root settings:
What if you want to merge only when several conditions are met? For example, do the merge only when tests on Linux, Windows and Mac OS pass. You can achieve that using snapshot dependencies:
- create a build configuration with a VCS root to merge and configure the auto merge build feature
- add a snapshot dependency to every build you want to succeed before a merge occurs.
As a result, the merge at the top of the chain will be performed only if all builds in its snapshot dependencies were successful.
To handle semantic conflicts, like the use of a removed class, you can create a separate ‘integration’ branch and use it as a destination for an automatic merge, and then configure another merge from the ‘integration’ to the default branch. The integration branch will sometimes be red due to uncoordinated changes in the parallel branches but the default branch will always be green and safe to deploy*.
The asterisk in the previous sentence means it was a lie . The automatic merge cannot guarantee green builds. If you run your build on multiple platforms or there is a lot of concurrency in your system, some tests may fail even if the previous build on the same revision was green.
So you have a build where some tests failed, but you know that the build is fine and its sources should be merged. To deal with such cases, you can merge the build sources manually. We added the Merge this build sources action on the Changes tab of a build. It allows you to choose a destination branch and do the merge. A manual merge is also useful if the push-only-when-complete workflow isn’t suitable for you, so you can merge the branch when it is ready from the TeamCity UI.
Subscribe to Blog updates
Thanks, we've got you!
Introducing AWS Connection: A New Approach for Working With AWS in TeamCity
We’ve introduced a new feature called the AWS Connection, which makes it possible to work with AWS credentials more flexibly and safely.
TeamCity 2022.10: Sakura UI, Improved Integration With Amazon AWS, Out-of-the-Box HTTPS Support, Google OAuth Authentication, and More.
TeamCity 2022.10 comes with the Sakura UI enabled by default, introduces many cloud-related features including the AWS credentials management system and out-of-the-box terminal access to AWS EC2-based build agents, and adds important improvements to VCS integrations. Server administrators will love the new streamlined way to implement HTTPS for on-premises TeamCity installations. Also, a new authentication module for using Google accounts and a number of long-requested features have been implemented.
Transition to native Git in TeamCity 2022.04 brings 10x fetch time reduction to IntelliJ Platform
Starting from version 2022.04, TeamCity switched to native Git on the server side for Git VCS connections. The switch should positively impact both performance and overall experience of working with Git repositories on the TeamCity server side.In this blog post, we’ll talk about the reasons for the …
TeamCity 2022.04: Parallel Tests, Improved Integration with Amazon AWS, Built-in Code Quality Analysis, Updated VCS Integrations, and more
TeamCity 2022.04 introduces the new Parallel Tests feature that delivers an extraordinary speed boost when testing your projects. New powerful code analysis features will cut the time you spend on code reviews and increase the maintainability of your projects. Users who run their builds in the cloud…