Is there any option to trigger build ONLY for entire pull request (only on merge)? I could not find any info about that option, in triggers settings there is only "Include several check-ins in a build if they are from the same committer" option. Will triggering on "Merged" comment works?
I tried to create a trigger but there's no option for this.
In my team we're using teamcity 2020.2.4.
If you limit your branch spec to only watch master, it will only trigger when commits are made to master. Given that you are performing PRs from feature branches to master, a build set up to only trigger (limited by the branch filter in the CVS root) on new changes, will only trigger once the merge commit (or any other commits made to master) have been made.
The workflow you describe puts some requirements and limitations on the process that you work with and disallowing commits to master from everyone except the build system / VCS is one such rule you could set in place to achieve this.
The other setting you mention, "Include several check-ins in a build if they are from the same committer", will let TeamCity bundle together the changes included in a build, if the commits come in within the allowed time limit (defaults to 1 minute, if I remember right). If this setting is not enabled, all commits - even those which come in one after the other within a very short time frame - will trigger a new, separate build.
I'd generally advise to enable that option and set the timeframe to 1 minute or whichever suits your team the best.
Related
I have this trigger in my build configuration to trigger this build only when specific files are modified (and skip another not related to production). Build is tested and deployed to production environment. Trigger works correctly.
But what I am trying to solve are pending changes. Changes committed to VCS that are not triggered for building process and remain in interface.
Q: How to get rid these pending changes?
I can run build to remove them but by running build I do a deploy to production server, and I do not want to do this. What's the point of triggers when it is not possible to get rid of pending changes and the build has to be started manually in order to get rid of them?
I think a quick explanation of the available toolkit would be beneficial:
Trigger rules vs. Checkout rules
A VCS Trigger rule is a rule that specifies which particular changes you want to actually start the build. A Pending Change is an indication of which changes were added to the scope of the entire VCS root since the last time your build was run. This would, in many cases, indicate the differences between the source code and the latest compiled artifact, as an example.
What your build currently defaults to is that all changes in the VCS are relevant to your build, and that only a (small) subset of these changes should actually trigger a new build. In other words, TeamCity is "keeping an eye on" all of the changes relevant for your build, i.e. the entire VCS root scope.
A Checkout Rule is a rule which limits the scope of the VCS root. It specifies two things: a) the subset of the VCS contents that you wish to checkout on the agent and b) the subset of the VCS contents that you wish is tracked for "Pending changes".
One option
If you want to limit the scope of the VCS for that one particular build, one option is available for you. You could for example create a checkout rule that is similar to your trigger rules, i.e. specifying that you only want to checkout and track the paths from your trigger rule, this will then only show you "Pending Changes" for changes that match these rules. The downside of this method is that you may not checkout all required files for the job, and may not notice they are missing until your piece of software is deployed to production (what if images are not in /src/main/**, or sound files - they won't be included this way, then, unless explicitly included in the checkout rule).
Another option
...is to simply ignore the "Pending changes" number and list for that one job, if you need all of the VCS content to do a deployment.
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
If there are multiple pushes to branch, Bamboo schedules separated builds for every push which creates redundancy on the queue. We only care about the last build with the latest changes for ours pull requests. Therefore, is there any way/configuration to cancel ongoing/scheduled builds if new build is scheduled?
I figured out Enable quiet period option (Quiet period allows you to delay building after a single commit is detected, aggregating multiple commits per build). However, quiet period is not the best way to handle the redundancy on the queue.
Does anybody have any idea?
A few things:
It is somewhat of an anti-pattern to avoid building each time code is committed. If you cancel an ongoing build, you could theoretically go all day without ever knowing if a commit at the beginning of the day broke the build if incoming commits keep cancelling the build. Taking this approach you would lose the benefits of having a continuous integration system.
If you only care about the builds going into your mainline branch then you can edit how branches are built by going to Plan Configuration -> Branches. You can select Manually or "When pull request is created". The latter will only trigger a branch build when the PR is created and is updated.
You can further limit what is running by using the Conditional tasks for Bamboo plugin. While not as clean as not starting a build, you could choose to only execute time consuming tasks when your main branch is building, which would allow for faster execution on branches.
Finally, you could theoretically use the REST API to create your own custom plugin/application that stops builds.
TeamCity automatically kicks off builds for the branches created by GitHub Pull Requests. This is all fine, and its "Active Branches" list has the same number of items as there are Pull Requests in the monitored repository.
However, if I go to run a custom build for a specific branch, the "Build branch" list has many, many branches, the vast majority of which have been merged and deleted (we've got nearly 400 in the list now):
Is there any way to clear this list down to only show Active Branches?
(this is TeamCity 10.0.4)
As far as I am concerned, the inactive Pull Requests that were shown in the UI were Closed Pull Requests.
As a workaround, instead of using the run command which display a combobox which is not filtered, I use the dropdown inside on the top left corner at the project level, and not at the build configuration level.
If there is more than Closed Pull Requests, but merged one in the list, you should consider to set the parameter: teamcity.activeBuildBranch.age.hours to 0.
You can also reduce the number of showed inactive branches by adding the parameter: teamcity.branchChooser.inactiveBranchesLimit with the desired amound of inactive branches.
the vast majority of which have been merged and deleted
If you absolutely sure that all of them have been deleted in your Repository and you still see them in TeamCity that means only one thing: you keep whole history of all your builds in TeamCity.
If you setup custom Clean-up policy for your build configuration you will reduce number of inactive branches in this list.
As variant you can make special build configurations for your Pull Requests and apply custom Clean-up policy only for it.
We're using teamcity with github enterprise. And we have it set to run on merge requests as well as commits. However, git keeps sending teamcity commit messages for merges that have 0 file changes, which triggers a build.
For example, this will trigger a build:
I've found the documentation here for creating a trigger filter
But I don't see a way to create a filter on the number of updated files.
I think this is what's causing the builds
Triggering a Build on Branch Merge
The VCS trigger is fully aware of branches and will trigger a build once a check-in is detected in a branch.
When changes are merged / fast-forwarded from one branch to another, strictly speaking there are no actual changes in the code. By default, the VCS trigger behaves in the following way:
- When merging/fast forwarding of two non-default branches: the changes
in a build are calculated with regard to previous builds in the same
branch, so if there is a build on same commit in a different branch,
the trigger will start a build in another branch pointing to the same
commit.
- If the default branch is one of the branches in the
merging/fast-forwarding, the changes are always calculated against
the default branch, if there is a build on same revision in the
default branch, TeamCity will not run a new build on the same
revision.
It's worth noting, that builds on branches that haven't been updated will be triggered by a merge in another branch.
You probably use checkout rules. Otherwise, running a build on a merge commit with 0 files seems an appropriate action: the commit does change the content of the checkout directory and should trigger a build.
If you limit what you checkout via TeamCity checkout rules, TeamCity only displays the merge commit with 0 files if it actually changes the content of the checked out directories (by merging files in the directory), or the commit graph is not fully known to TeamCity, and it potentially can affect the checkout.
If you are not running the latest TeamCity release (10.0.5 as of now), it makes sense to update. If you still get merge commits displayed which are not affecting the checked out files and are not merging commits created before the VCS was configured in TeamCity, it makes sense to report the details to TeamCity support.