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).
Related
I have some branches that I use for release release/vX.x.xx.
I want to always run a build for the latest change on any of this branches (the last one modified, I don't care for the other ones) as a scheduled nightly build.
I configured the VCS root to aim to refs/heads/master (the release branch always change so I can't aim to that one as the default)
branch specification: +:refs/heads/(release/*)
In the triggers, I set a Schedule Trigger with Additional Options > Trigger Build in Branches set to +:refs/heads/release/*.
I also tried to set Triggering Conditions > Edit Trigger Rules to +:refs/heads/(release/*)
Although I did all this, and I see the x pending in the Build configuration tab, when the scheduled time arrives, it doesn't build any branch.
How can I set it up so it will always build the latest change on any branch that matches the pattern in my scheduled trigger?
I'm using TeamCity 2019.2.2
I have a project that needs to execute either three or four build steps depending on the branch in source control. More specifically, if I'm merging in a PR and running the build (for GitHub status notifications) I have one extra build step that is required.
It's that last build step that I need to omit if it's a non-PR branch.
Is there a way to add a build step that checks the trigger and exits the build successfully? Or a way to exclude a build step based on a branch filter?
You can check the condition and modify the step logic inside the build script. See the related ticket and an example of the script.
BTW, It is not a good practice to change the logic of the build inside build script. In this case you no longer "compare" builds in the build configuration: they start to form multiple unrelated sequences. Also the statistics of the builds will be uninformative. The recommended setup is to create several build configurations based on template.
Depending on which type of runner you are launching, but you can, in some cases, add few lines of code to get your current branch name with the property : %teamcity.build.branch%
In my case, I just add this as an extra parameter for powershell scripts and if this is a number, do something, else, do other stuff. ;)
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.
TeamCity 8.1.4 (build 30168)
I notice that Build Features are always run as first part of first step in the Build Steps, but is it possible to make a Build Feature run e.g. as first part of step2? Or as last part of Step1?
Any help is appreciated!
(If it is of interest, this is my concrete problem;
I have a meta runner that creates a specific build number, I use this as a first step in the build steps. I want to use the build feature "AssemblyInfo patcher", but this runs before the meta runner has done its thing)
Create another build configuration, move your meta-runner there.
Modify your build parameter to report a build number through service message
Create a snapshot dependency from your build configuration to the new one
In the configuration with meta-runner go to general page, enter %dep.META_RUNNER_CONFIG_ID.build.number% to 'build number' field. This will take a build number from the dependency and set it as a build number. META_RUNNER_CONFIG_ID is the Build configuration id you will see on the general page of your configuration where you have moved meta runner.
Use %build.number% as a replacement in AssemblyInfoPatcher
I'm trying to figure out how to configure TeamCity build steps to accomplish the following tasks:
Call a console app that merges the dev branch to the test branch (in
TFS) and modifies some of the files manually in the test branch that
are used for the projects configurations. This process works perfect
and has been tested. Also note, this step does not check in the
merged files or modified files to the test branch.
This build step will kick off the actual solution build for the test
branch. (This is C#.NET, but I don't think that is significant)
This build step handles the database migration for any SQL scripts
added. (This step has also been tested and works)
This step calls another console app. This step will run even if a previous steps fail. If the build has been successful it will check in the pending changes from step 1, and do the deployment of the build. If the build has failed in a previous step, it will undo the pending changes from step 1.
That seems simple enough to do, but I the interaction between steps 1 and 2 is what I don't know how to do. If I use server-side checkout for step 2 it will pull the source from the server and not use my changes in step 1. If I user agent-side checkout, my understanding is that it will create a new workspace and pull the source from the server, again not using my changes in step 1.
Is there a way I can make step 2 build with the pending changes created in step 1? The only other option I can think of is to check in the changes after step 1 and rollback the changeset in step 4 if the build fails. In that case though, how would step 4 know the changeset to rollback?
Also I have one smaller question, how can I pass the success of the build as a parameter to step 4? I looked through the built-in parameters but I didn't one for build failure/success?
Thanks!
It would be useful if you could give the VCS name you are using(Git/SVN). I see you question is mainly on 2 main points
If you are using Teamcity build Steps , where in all build steps
are part of a single target you do not have to worry about
interaction between Step 1 and Step 2 . All steps can run in the same
directory . You always retain your working copy status throughout
the sub steps.
The only glitch in teamcity is that you can not run a build/step "only if
a previous step fails". To get around this, you can create a failure
file in any of the previous steps and run the build only if that file
is present. Delete the file at the end of every build just to ensure
that there are no accidental issues in the next build.
So, in short your build steps can (1) checkout a branch, (2) merge another branch into it , (3) run build and db deploy, and then (4) commit your code /rollback your db changes if it fails based on a failure file.
For your second question, each teamcity step knows the success status of the entire build and the previous steps as mentioned here . The only step missing is " run step if any of the previous step failed"