I have TeamCity builds that linked to one VCS root. Fetch URL of the VCS root is parameterized. Every build is configured with its own git url. This works as expected: git only triggers build with the right url.
Then I have a deploy with snapshot dependencies on all previous builds:
All of the sudden, sometimes TC triggers undesired rebuilds, even if there are no changes in a repository. Builds are triggered by snapshot dependency.
I am investigating why rebuild happens, as it leads to overhead and produces too much docker images.
I found complex logic that depends on whether VCS roots same or not https://www.jetbrains.com/help/teamcity/dependent-build.html#Snapshot+Dependency.
Are links to VCS root with different fetch URL considered the same VCS root?
Ok, I have made copies of the VCS root and actually it behaves the same as one VCS root with parameterized Fetch URL. E.g. my problem still remains: sometimes snapshot dependencies trigger all the builds even if there are no changes in the repository.
Related
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.
My build configuration pulls code from multiple vcs roots. As part of my build process I build an open source project from github, which unfortunately has just introduced a dependency that breaks the build on my server.
Is there any way I can change the specification of the VCS root to limit it to the commit before the dependency was introduced? I don't want to manually run a specific commit as this would force the other repository in the build back to the same point in time, which would mean I'm never building my latest code. For reasons outside of the scope of this question, I need to build all projects from source, so can't take a pre-compiled version.
Is it possible to force teamciy to always check out the same commit of a VCS root?
Most of projects are using tags to identify versions so probably you can use it.
Or if you always need only one version you can fork repo and add branch/tack on your copy
Unfortunately git refspec does not provide possibility to specify commit by hash.
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.
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).
Right now, TeamCity is creating 2 sets of artifacts each time I do a successful pre-tested commit, one when it builds the solution with my local changes against which to run the tests, and a second time when it gets triggered by the VCS repository change.
How can I prevent it from creating artifacts for its build-to-test before commit?
Check build.is.personal system property or BUILD_IS_PERSONAL environment variable to be defined.
Use a different build configuration for the VCS triggered build, one that doesn't have any paths configured for saving Artifacts.
Go to the Administration page and copy the existing build configuration.
Under "Build Triggering" on the original configuration, disable "Enable Triggering when files are checked into VCS"
Under "General Settings" on the copy remove everything from Artifact Paths