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. ;)
Related
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.
This is a more generic version of this question: How to run a build step on a specific branch only?
For example, I can use a PowerShell script to run MSBuild if '%teamcity.build.branch.is_default%' -eq 'true' or if '%teamcity.build.branch%' -eq 'master' but then I will miss the collapsible log that comes with the TeamCity MSBuild build runner. Isn't there any easier way to conditionally run a build step?
It is not possible to execute build step based on condition. Vote for the related request: https://youtrack.jetbrains.com/issue/TW-17939.
The recommended approach is to create separate build configuration for each branch. You can use templates to simplify the setup. In this case it will be easier to interpret the results and the statistics of the builds will be informative.
Also see the related answer (hack is suggested).
JetBrains introduced support for conditional build steps in TeamCity 2020.1.
Here is a snippet of their blog post announcing this new feature:
Have you ever wanted to execute different command line scripts on different platforms, or deploy changes in different branches to different staging servers? Now you’re free to do just about anything! TeamCity 2020.1 allows you to specify conditions for your build steps and execute them only if the criteria are met.
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
We have a teamcity build, triggered by git, that is doing git integration, sometimes checking into the current branch (it's updating the branch from another source). This obviously creates another check-in on the same branch, and causes the trigger to see it.
Ideally, I'd block the trigger from seeing that second check-in, but I can't seem to find a way of doing that - as what we are checking in is a conglomeration of changes from other sources. I know the last change is from the build system user, but can't see a way of excluding based on the result of the most recent change.
So I built something in the build script, that correctly ascertains we shouldn't go ahead with this build. I'm currently just failing - but this isn't actually an error case. I want to stop the current build without doing any further steps, but I want the result to be green, and everything to be fine. Is this possible? I tried doing the ##teamcity set status, but that didn't work.
I actually "solved" the problem, with a brain-dead but easy hack - I just set a variable "skip", and check it at the start of each subsequent step. Ugly, but for the moment - it works.
You can set a VCS trigger rule (5 Build Triggers) with an exclude rule that will not trigger when the build system user commits to your repository. The exclude rule would look something like this:
-:user=TeamCityUser
Hope this helps!
You can filter out triggers by commit messages. When checking-in from the build agent, always check in using a predefined and specific message. Then you can change the build trigger to not fire when that specific message is part of the commit
I have created many build configurations in Hudson for a single solution (eg. Release, Debug, Test)
When I commit something wrong, I receive 1 build failed e-mail for every build configuration.
I would like to receive a single e-mail.
I think if I could to make one build dependent on the success or failure of another, I could receive less e-mails.
How to do that?
BTW: I use MsBuild, Subversion and NAnt
It sounds like you have multiple jobs (build configurations) for the same set of source code that are configured to always build. You could, as someone else suggested, use build triggers to chain these jobs together. However, if all the jobs run on each commit, I suggest combining the jobs into a single job with multiple steps. That way when one step fails, the entire build will fail, no unnecessary Hudson cycles will be spent, and you will not receive redundant emails. To add steps to a build, click "Add build step" and select "Invoke Ant" (or whatever other action you want it to take).
You can use the build trigger "build after other projects are build" to put projects up- or downstream from one another. Then you typically let the lighter builds go first (like simple compile).