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.
Related
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.
I got a project that is stored in svn and let's say mirrored in git.
Long story short: svn has bad connection, so we don’t branch in svn, use git through "git svn" to synchronize repositories and creating feature branches in git.
Earlier we got two build projects in TeamCity to handle that, but now I added few deploy projects that depends on a build artifacts, so I don’t want to duplicate them too.
In TeamCity, during the build I would like to prompt what VCS Root to use.
So, I added two VCS Roots, setup connections, setup checkout rules and set "VCS checkout mode" to "Do not checkout files automatically".
As I understand now I need to create a build step to manually checkout files from the chosen repository.
Is there something inside TeamCity that can allow me to reuse VCS Roots (and checkout rules) I already setup?
I mean is there any command that can checkout just by providing “VCS root ID”, or should I redefine all checkout rules completely on my own?
One of the approaches would be to utilize conditional build steps.
Set up two different build steps that perform manual checkout from each repository and execute them based on a parameter's value. You can then configure the parameter to have the 'Select' type. Optionally, you can set its 'Display' value to 'Prompt' so that TeamCity will always ask you to select one of the pre-defined values.
Note that checkout rules won't directly affect manual checkout. They are only applied when auto-checkout mode is used. They will still affect revisions that are attached to builds in the UI, though.
Another approach is to set up a simple build chain by adding another build configuration in front of your main build config. The first build in the chain will perform a REST API call that updates the checkout rules on both VCS roots that are attached to the second config. You can set the -:. rule to a VCS Root that you don't want to be checked out. To make things simpler, you can store checkout rules in parameters, and assign these parameters to checkout rules of your VCS roots. The benefit of this approach is that you'll be able to use auto-checkout in your main build configuration. Again, you can utilize conditional build steps here to define which REST API call should be executed.
I've configured vcs trigger to monitor only specific directory like this "+:SomeDirectory/**" and it was working fine when my VCS root had 1 branch configured. Recently I've made a change and configured VCS root to listen on multiple branches.
I've got feature branches based on main develop branch and i wanted to trigger build only if specific directory has been changed. Unfortunately with this configuration teamcity triggers additional build for every brand new feature branch (it assumes that it's new branch thus there are changes in directory). So i have 2 builds: if anything changed in this directory and build if branch is new.
Is it possible to trigger build on feature branches only if something changed in "someDirectory" according to my main development branch?
Yes, you do this by adding a VCS Trigger at the Trigger configuration page, where you can specify, among others, the "Branch Filter". Here you can also create VCS Trigger Rules, where you can specify which "VCS root" will trigger the build, for which directories.
Please note that the VCS Checkout Rules might influence the paths used in the VCS Trigger Rule!
E.g. consider having two VCS Roots attached to the build configuration, with checkout rules:
master-vcs-root +:. => master
feature-vcs-root +:. => feature
So the master-vcs-root checks out into [agentpath]/master, and the feature-vcs-root checks out into [agentpath]/feature.
If we only want the trigger fired based on changes made in a specific directory on the feature-vcs-root, the Trigger Rule should take the checkout directory into account:
+:root=feature-vcs-root:feature/someDirectory/*
and not
+:root=feature-vcs-root:someDirectory/*
This was found working on TeamCity Professional 2017.2.2 (build 50909).
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 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.