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.
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.
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.
So while this is completely do-able (albeit using some fairly fancy scripting) in Jenkins, I'm just wondering if it's do-able in VSTS.
I'm not too familiar with capabilities of VSTS (have read https://learn.microsoft.com/en-us/vsts/build-release/actions/ci-build-git).
I want all changes pushed from a feature branch to master to be automatically merged into all other active feature branches. So basically, I want (what I call) true CI.
Is this possible in VSTS, and if so, how would I do it?
EDIT 1:
Read this:
https://learn.microsoft.com/en-us/vsts/build-release/actions/scripts/git-commands#merge-a-feature-branch-to-master
This would work for me by simply switching the merge direction; instead of merging from feature branch to master, merge from master to feature branch.
So the question now becomes:
How to get a list of all active child branches?
Given that I'll be using work items mapped to branches, would this suffice?
https://learn.microsoft.com/en-us/vsts/report/extend-analytics/work-item-links
No, it is not supported in VSTS, with Pull Request it just can merge source branch to a target branch.
The workaround is that you can create the Pull Requests for related branches during the build/release, refer to this thread for detail steps:
How can I create a Pull Request when a release completes in VSTS?
Update:
The other way is calling git command to merge branches: Merge a feature branch to master
Regarding active branch, as we discussed, you can link them to a work item, the work item has the TO DO, In Progress etc... states that can identify different "state" of branches, and you can retrieve the work item through Work Item REST API.
I have the following scenario:
I have a Dev and Stage branch
Code is checked into Dev, and at some point those changesets from Dev are merged into Stage
No direct edits/check-ins happen to stage (beyond the merges from dev)
What I want to do is identify/verify that no new code has been introduced directly into the stage branch which did not originate from a changeset in Dev.
It does not appear possible to secure Stage (from a source control perspective) to only allow check-ins of merges from dev (since all operations appear to be merge,edit after I do the merge), so what I thought I could do is create a TFS Check in policy which attempts to compare the merged changes to their source.
I have created a class which derives from PolicyBase and have over-ridden the Evaluate method. In the Evaluate method, I spin through this.PendingCheckin.PendingChanges.CheckedPendingChanges and check the .IsMerge property and .ServerItem property to see if the item in question is a merge and is destined for my Stage branch.
When I spin through each change however, I don't see a way to track its lineage or access the parent from where it might have originated (ie: the Dev branch version #).
How do I only allow merges, but no direct edits on my Stage branch?
The only way to achieve this in TFVC is for you to take ownership of all merges. If you do the merge then you have the control. Many organizations with these sorts of draconian policies create an automated script that does the merge and rejects if there are any conflicts. That way the developer is forced to pull from Staging to Dev and resolve all conflicts before requesting the merge through a web portal. If the merge is successful it was conducted on a server by a single service account and no coder required permissions to Staging of any sort.
This is however dysfunctional. Either you don't trust your coders, or they are not competent enough to work in your code base.
Another method might be to move to Git in TFS for source control. In Git merges are non-editable and are performed as a single action rather than the merge/edit you get in TFVC.
I have a build configuration that uses sources from multiple repositories. Thus, changes from all those repos go to the product. But in the process I want to know which specific repos had any changes. I couldn't find anything in the build parameters. Is there any way to get this info in the build process?
Thanks,
Zura
I suspect you've probably already come to your own conclusions on this because it seems to be standard TeamCity functionality you're asking about, but here are my notes based on my brief time using TeamCity for the sake of completeness:
A build configuration can have multiple VCS roots attached to it, and by default will start probing each root for new changes every 60 seconds
Once changes are detected for one or more of the roots, the build configuration will show "Pending(n)" next to it where n is the number of changes it's found.
If you click the triangle next to the Pending message, you see details of who committed the change a comment, and a filecount.
If you click the filecount, it will popup a list of the files, and the name and revision of the VCS root it came from.
When the build is triggered, it will remember all this change detail so you can go back later and query which changes were used in each build execution, including which VCS root and revision they originated from.
So, changes from multiple VCS roots are interleaved with each other and easy to trace. You mention "build parameters" which is also useful, and logged, however it's more about the state in which the build agent itself runs in such as filesystem paths, environment variables or parameters passed specifically into the build configuration.