Using TeamCity 2020.2.4
Build job has multiple VCS Root set up comprised of "source code" and "utility scripts".
The "utility scripts" are always on same branch (master); however, the "source code" is either in master (aka: default) or release/### branch.
The "source code" root has:
Default branch: refs/heads/master
Branch specification:
+:refs/heads/(master)
+:refs/heads/(release/*)
Currently there are 2 builds, one for master (longer running builds), and one for release (does bunch of extra steps to prep for release).
Initially there was a desire to just hide the "master" default branch from displayed, thus followed TeamCity's own docs (https://www.jetbrains.com/help/teamcity/branch-filter.html#Branch+Filter+Format) that imply I can tweak Branch Filter:
+:*
-:<default>
(also some SO articles that mention this as an answer, but years old)
However when doing so, end up getting error:
Failed to collect changes, error: Builds in default branch are disabled in build configuration
Looks like triggers run just fine, but it's the Manual build where things really go sideways.
Have tried even overriding with teamcity.build.branch with a default + prompt parameter, no such luck.
Have seen circumstances where wrap it in another job, but that's bit hacky just to do what TC says should be possible directly.
Found a solution, posting here to help the next person ...
So, despite TeamCity mentioning "logical branch name" for the "Branch Filter" in Version Control Settings, can actually provide full branch name.
Thus "refs/heads/master" can be used. This effectively seems to allow one of the VCS roots to continue using it's default/master, while allowing other options for the 2nd root.
For example:
VCS Root #1 config:
Default: refs/heads/master
Spec:
+:refs/heads/(master)
+:refs/heads/(release/*)
VCS Root #1 config:
Default: refs/heads/master
Spec: (empty)
And when doing different jobs, the Branch Filter would be set as such:
"master only":
+:refs/heads/master
+:release/*
-:master
"releases only":
+:refs/heads/master
+:<default>
+:master
Worth noting, despite that even though "master" is default, still need to actually specify both ... at first pass might not seem intuitive, but it is what it is - and it works.
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 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 have several projects that produce NuGet packages that I publish to an internal server. We're using semantic versioning, and using tags in our Git repository to control the version numbers.
I'm tagging like this:
git tag -a v1.0.0 -m "tagged"
And, during the TeamCity build, I run git describe --long, which produces an output like this:
v1.0.0-0-ge9c047d
The fourth number in the output is the number of commits after the tag. The 0 here means that no commits have been made since the tag. I use these first four numbers as the version number (and, incidentally, the entire string as the AssemblyInformationalVersion).
I have TeamCity package and publish a NuGet package, but here's where it gets sticky. I only want to publish tags, never commits after tags (because the version number in that case would be wrong, possibly VERY wrong).
I've tried setting the "branch specification" in the VCS root to "+:refs/tags/*", which causes all the tags to be built, but TeamCity also insists on building the "default branch" as well. If I set the "default branch" to something that doesn't exist, I get an error.
I've thought about ending the build early if a particular build isn't a tag, but I can't figure out how to do that without FAILING the build, which isn't what I want.
How do I cause one or more build steps to only run for new tags, and not regular commits?
If you are using TeamCity 8.x, there is now support for VCS branch triggers, which would allow you to not run builds from the default branch.
Try this:
Leave the Branch Specification in the VCS Root as "+:refs/tags/*"
Change the VCS build trigger rules to:
+:*
-:<default>
This will filter out the default branch from the trigger and you won't need to cancel the build.
I've got a CI build pulling feature branches from Github and building/packaging them into a local folder, using a folder naming convention based on the project, branch and build number.
For named branches (feature1, feature2) this is working great.
The problem is that when I do a commit to the master, TeamCity exposes teamcity.build.branch as <default> - which means when the build step expands
E:\Packages\MyProject\%teamcity.build.branch%\
it's ending up with E:\Packages\MyProject\<default> - which is then crashing the build step because it isn't a valid Windows path.
I can see the master branch name in the fully-qualified build parameter:
teamcity.build.branch <default>
teamcity.build.checkoutDir C:\TeamCity\BuildAgents\agent-mulder\work\2151838a7933464d
teamcity.build.default.checkoutDir 2151838a7933464d
teamcity.build.id 16347
teamcity.build.vcs.branch.github_myproject refs/heads/master
but ideally I need to get master as the teamcity.build.branch for use in my build steps.
Can I transform the parameter at runtime? Override the behaviour? I've even tried setting the VCS branch name to DO_NOT_USE in the hope that "master" would no longer match the default - but this doesn't appear to work either.
In teamcity 7 its simply %vcsroot.branch%
that returns develop.
In my case I have
%MajorVersion%.%MinorVersion%.%PatchVersion%-%vcsroot.branch%
Which are all set in build parameters.
The number format is %BuildFormatSemVer% which is the stuff above and . {0}
%BuildFormatSemVer%.{0}
Which returns
#1.0.0-develop.4
Not ideal, but I was able to work around it by creating a new branch in git named "teamcity" and setting that as the default branch in TeamCity, it seems to require that the branch actually exist, since it worked when I created the branch, but didn't when you just entered a fake name.
Hopefully they actually fix this, because this is definitely a hack.
We have run into this problem several times when creating pipelines. It is the most visible when trying to automatically build feature and release branches using the Gitflow workflow. What we've been able to do was to use teamcity.build.vcs.branch.github_myproject and a regular expression in sed to sanitize the string whenever we wish to use it. This is mainly to watermark artifacts for debugging purposes.
The larger issue, at least for us, is that the TeamCity 7.1.1 version does not automatically fire off dependency builds for anything that isn't the default build in the VCS root. Obviously this is a huge pain point as we're now going to have to click manually in the tool. We haven't yet figured out a clean way to get around this other than hooks in git which use the HTTP API to call out to the proper build step.
I don't know if this was previously answered, or is any longer relevant.
In TeamCity 10.0.2 create a custom parameter such as %Git.Reference%. If you require a pull (or push) from TC to git, set this to "ref/head/Dev" or "ref/Head/yourbranch". Use this in your 'VCS root' reference.
I'm dumb with continuous integration and noticed a behavior that does not seem right..
I'm using Mercurial with TeamCity. When I push changes the TeamCity detect the changes but don't run the build automatically. This is correct behavior? He should not detect the changes and run the build automatically?
Triggers are not added to build configurations by default in TeamCity. You'll need to go to the settings for the configuration and click on "Build Triggers" then "Add Trigger". The type of trigger I believe you are looking for is a "VCS Trigger".
The documentation for this feature can be found here.
I believe my issues was misunderstanding what was needed in Branch Filters. I thought I was supposed to enter the GIT refs I wanted to have builds triggered from
This wasn't working for me
+:refs/heads/*
-:refs/heads/releases/6.7.3
-:refs/heads/releases/6.8.30
-:refs/heads/releases/6.8.32
-:refs/heads/releases/6.8.34
And this is what finally figured out (I think) is that it is asking for the branch names inside TeamCity itself (the help text says "Newline-delimited set of rules in the form of +|-:logical branch name")
This worked for me, to trigger builds from the branch (GIT ref refs/heads/master for me, look back in your VCS Root setup) and all other branches except those labeled "releases/6.7.3", "releases/6.8.30", "releases/6.8.32" and "releases/6.8.34"
+:*
-:releases/6.7.3
-:releases/6.8.30
-:releases/6.8.32
-:releases/6.8.34