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.
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'm using TeamCity 2017.1.4 along with GitVersion.
The teamcity project itself consists of many build configurations the first of which is to run GitVersion and then all subsequent steps take a snapshot dependency on this step and pull the version from its parameters.
In most scenarios this works great, however if we create a new branch eg. /release-foo and push this, teamcity will not trigger a build because its already previously built the commit sha, unfortunately we need it to trigger again as even though the commit hasn't changed being in a new branch means it will get a different GitVersion number.
I've tried forcing the snapshot dependencies on the GitVersion build configuration to always be rebuilt but this seems kind of ugly as kind of breaks all other scenarios where this isn't a problem. I also know I could manually trigger the build telling it to rebuild all dependencies and it would work, however I'm curious if there's a nicer way to get teamcity to automatically trigger a build for a commit on a branch if that branch didn't previously exist, or indeed any other way I could approach this.
You could try configuring TeamCity to include different/more GitVersion version variables in the build, including the branch name and possibly version tags. This would provide a way for your build process to differentiate between the same commit on different branches.
See steps 1-5 of this CD post, as well as this detailed blog post on using GitVersionTask for some examples on how to use the additional info in TeamCity.
You can achieve this by triggering the build from a git hook.
As explained here, you can use a the update hook to identify pushed branches (even when several are pushed in a single operation) and for each branch (assuming it passes your triggering rules) trigger a TeamCity build using the REST API.
If you simply amend the commit on the new branch without modifying anything, it will get a new hash because of timestamp changes. I wouldn't consider this a nice solution, but imho it's better than triggering manually.
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.
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).
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.