We have set up TeamCity' "failure conditions" to fail build if code coverage metric is bad. The exact condition is to fail build in case code coverage metric has dropped down by several percents.
Sometimes we build a branch which is building for the first time. These are basically release branches. We build them once.
The problem is that TeamCity fails while building new branches. It says, code coverage is bad.
In logs I see that TeamCity cannot find previous build for my branch. Indeed, it needs some previous build to compare code coverage and cannot find it because the branch is new. And as a result it is using some "anchor" branch for comparison.
"Anchor" branch is some old outdated branch which has bigger code coverage. So the evaluation of condition is correct.
The problem is that in case I am building a first build of some branch I expect one of the folowing behaviours:
disable code coverage metrics which need previous build which is missing
use some meaningfull "anchor" build to compare with, not some outdated build selected by some unclear to me way.
How can I fix it?
People on TeamCity forum helped me with the answer.
It turned out that TeamCity is trying to find some previous build of the branch we want to build to compare metrics with current build. In case previous build is not found it takes some build from default branch.. In our case it was some branch from another release and we were surprise to see that comparison of metrics.
The solution for new branches is either to make default branch some test branch with zero metrics so that new build always has better metrics, or just turn off metrics each time a new branch is build.
Related
I'd like to fail feature branch builds if they have less test coverage than the last successful build of master
I tried adding a extra failure condition by following the steps here
https://www.jetbrains.com/help/teamcity/build-failure-conditions.html#BuildFailureConditions-AdditionalFailureConditions
But I can't find a way of referencing the last successful build of master
Is there a special tag automatically set to the "default" branch or do we need to add some code to the build step to auto pin / auto tag it?
Could you add a custom build metric and use a build step to only set the metric when the master branch is being run? You could check the branch name in the TeamCity parameter and only set the value for master? Hopefully this will be easier in the future with conditional build steps (unfortunately not available at the time of answer).
I'm trying to setup a pipeline for running all kinds of tests against pull requests into my repository. Repository is git repo hosted with Bitbucket Server and TeamCity is Enterprise 2019.1.5 (build 66605). There are a few key aspects to the task:
There's a lot of tests. One way or the other tests should run in parallel to achieve reasonable execution time. The tests are already partitioned as separate TeamCity build configurations, each having good enough execution time.
There's much less build agents available for the task, so it's not impossible for a particular build to spend quite some time (up to 1-2 hours) in a build queue.
The result of the testing should be reported to Bitbucket as a single aggregate value. I.e. if there are, say, 3 individual builds from p.1 with two passing and one failing then Bitbucket should receive single "failed" build status.
Ideally, pipeline should be triggered by a feature branch change (refs/pull-requests/123/from in Bitbucket lingo), but checkout merges of the feature branch into target branch (refs/pull-requests/123/merge in Bitbucket lingo).
Given above requirements, I experimented with Composite Build Configuration (https://www.jetbrains.com/help/teamcity/composite-build-configuration.html) as it seemed perfect fit for the job. So I set up single composite build with proper builds from p.1 as snapshot dependencies, "Pull Requests" and "Commit status publisher" build features. It works perfectly, except for one thing...
The only thing I cannot seem to be able to work around is the fact that VCS roots in the dependencies collect changes when the build chain is added to the build queue. This means that because of p.2 (non-negligible max time spent in build queue) some builds end up running against a little bit dated sources. Ideally, I would like to be able to run the builds against the latest sources.
So my question is if there's any way to disable revision synchronization for dependencies? Or maybe I could approach the whole problem in some completely different way without using snapshot dependencies?
Cross-posted at community forum: https://teamcity-support.jetbrains.com/hc/en-us/community/posts/360006745840
I'm using TeamCity 2017.1.4 along with GitVersion.
The teamcity project itself consists of many build configurations the first of which is to run GitVersion and then all subsequent steps take a snapshot dependency on this step and pull the version from its parameters.
In most scenarios this works great, however if we create a new branch eg. /release-foo and push this, teamcity will not trigger a build because its already previously built the commit sha, unfortunately we need it to trigger again as even though the commit hasn't changed being in a new branch means it will get a different GitVersion number.
I've tried forcing the snapshot dependencies on the GitVersion build configuration to always be rebuilt but this seems kind of ugly as kind of breaks all other scenarios where this isn't a problem. I also know I could manually trigger the build telling it to rebuild all dependencies and it would work, however I'm curious if there's a nicer way to get teamcity to automatically trigger a build for a commit on a branch if that branch didn't previously exist, or indeed any other way I could approach this.
You could try configuring TeamCity to include different/more GitVersion version variables in the build, including the branch name and possibly version tags. This would provide a way for your build process to differentiate between the same commit on different branches.
See steps 1-5 of this CD post, as well as this detailed blog post on using GitVersionTask for some examples on how to use the additional info in TeamCity.
You can achieve this by triggering the build from a git hook.
As explained here, you can use a the update hook to identify pushed branches (even when several are pushed in a single operation) and for each branch (assuming it passes your triggering rules) trigger a TeamCity build using the REST API.
If you simply amend the commit on the new branch without modifying anything, it will get a new hash because of timestamp changes. I wouldn't consider this a nice solution, but imho it's better than triggering manually.
I am having a bit of trouble with the Branch Updater feature of Bamboo.
If a new commit is pushed on a branch that is using the branch updater, Bamboo checks if there are new commits on the dependent branch(in my case the master branch) and if this is the case it merges the changes and runs the build.
However, if this build fails, it is hard to recognize, if the new code on the branch itself is broken or if it just could not be merged correctly with the master. Therefore I would like that in these cases the branch is build independently first and only if this build is successful, the changes on the master are merged in and the branch is build again.
Is this possible using the branch updater feature?
A workaround might be to use multiple build plans and use one to build all branches isolated and another plan to integrate everything using the branch updater.
The "Branch Updater" feature is to merge the code from master branch into feature branch after a successful build of the master branch.
However, currently there is NO straight forward option in Bamboo (except the workaround mentioned in your OP) to build the branch and auto merge only if the branch build is successful.
Typically, the developer runs the build in local and commit the changes to repository if the local build is successful. There are two things that can go wrong.
1) While running the local build, the latest code from feature branch is not available in local. Some of the repos like GIT would complain if the local doesn't match with HEAD revision, you need to update to HEAD before you commit the changes. In this case, you can run the build again to ensure there is no problem.
2) When the master code merges with feature branch, something could go wrong
I understand that still there is a gap which can be addressed to resolve the point 2.
You can create a ticket in Bamboo with detailed explanation of the use case to add this feature.
I recently configured our build server using bamboo and Sonar. In our case we have a multiple developer environment and chose to not only analyse our trunk but also the branch. The nightly builds of trunk and branch are analysed by sonar. And there lies our problem. The last build will be the build saved in Sonar, which is plausible from a Sonar point-of-view, ie the projects have the same name so are probably the same.
In Branch we have fixes for our major release all projects name and code are same just in branch we have bug fixes. so we would love to see the analysis of branch and trunk separately in sonar dashboard.
The question is there is a way to make multiple version of the same project in Sonar? Or is there any other best practice in this situations?
Looking forward to you replies :)
Use the sonar.branch analysis property to distinguish the branches from head and from each other. Note that there are limitations. E.G. Issues marked "False Positive" in one version of the project will not show up as FP's in the other versions.
More analysis params in the docs