Teamcity: how to checkout root directory, but watch changes only from subdirectory - tfs

We use Teamcity 2018 together with TFS.
We have one project in which the structure is following
Root <---- We want to checkout the whole Root-directory
\ProjectA <---- We want to show changes only from the sub-directory
\ProjectB
\ProjectB
We would like to watch changes from Root\ProjectA-directory and display only changes that were done under that directory.
However, we would like to checkout the whole Root-directory and run our build from there.
Is there any way to do this?

Trigger rules can help you accomplish this. Within your VCS trigger, you can specify a collection of rules to filter in or out various conditions that will cause your build configuration to trigger. These are independent of your VCS rules and those rules will handle what you choose to checkout as normal. The rule syntax is as follows:
+|-[:[user=VCS_username;][root=VCS_root_id;][comment=VCS_comment_regexp]]:Ant_like_wildcard
The Ant_like_wildcard is the element of particular interest to you in this case, as you can use them (among other things) to filter in or out a particular directory.
Here is an example from the TeamCity Documentation:
"-:lib/**" prevents the build from triggering by updates to the "lib" directory of the build sources
Using your example, your trigger rule would look something like:
+:ProjectA/**
You can use a single inclusion rather than multiple exclusions because of the way TeamCity handles those types of rules:
When specifying the rules, please note that as soon as you enter any "+" rule, TeamCity will change the implicit default from "include all" to "exclude all".
You can find the full TeamCity VCS Trigger documentation here

Related

Avoid triggering build on certain file changes (e.g README.md)

Is there any way to avoid triggering build on certain file commits which are not directly related to source code?
e.g. I don't want to trigger a automatic build when anyone make changes to README.md file or some reference document file.
I don't know that it's described in the plugin page or the Wiki, but at least according to the Advanced Features/Additional Behaviors, the git plugin can be configured to do what you're looking for in multiple ways.
eg: Polling ignores commits in certain paths lets you specify an Included region or Excluded region" The help (?) says:
Each exclusion uses java regular expression pattern matching, and must
be separated by a new line.
myapp/src/main/web/.*\.html
myapp/src/main/web/.*\.jpeg
myapp/src/main/web/.*\.gif
The example above illustrates that if only html/jpeg/gif files have been committed to the SCM a build will not occur.
You'd have to try them out. One less plugin - KISS!
After searching for quite a while I finally found a Jenkins plugin which can skip the build when there is keyword "[ci skip]" in the commit message.
This allows to skip a build on any file commit which has this keyword [ci skip].
only disadvantage is, it will skip the build even if somebody puts [ci skip] in a code file commit
Github: jenkins-ci-skip-plugin

TFS Build Definitions: Use complex patterns in branch filter for triggering build

In TFS it is possible to set the trigger of a build definition to a specific branch (e.g. master). It is also possible to use patterns like so features/* in order to execute the build whenever there was a push to a branch underneath features/.
This already worked for me. In my use case now I want to trigger the build whenever there was a push to a branch with a specific version number in it.
E.g. Bugs/BUG1234/BUG1234_v1.2
I already tried things like **/*_v1.2, but it didn't work.
Did I miss something, or is it just not possible?
It's not possible for now, CI filter does not support such complex patterns. Please see Continuous integration (CI)-Filters for details.
As a workaround you can add multiple filters with the paths wich include the specific version number in it.
E.g.:
Include Bugs/BUG1234/BUG1234_v1.2
Include Bugs/BUG5678/BUG5678_v1.2
Include Bugs/BUG910/BUG910_v1.2
However the requirement makes sense, I have submitted a user voice here for you to suggest the feature. You can go and vote it up to push the Dev team to achieve that in future.

How to ignore JS and CSS files on gated checkin?

Is there a way to avoid the automated build when we checkin only js or css files?
It doesn't need to build anything, I would like to skip the build for these files.
I don't think it is possible to do what you are wanting to do- I don't think gated check-ins is that mature yet. There are quite a few outstanding enhancement requests for gated check-ins. It might be worth adding this as a request. Even cloaked folders are at the folder level and not the file level.
From MSDN:
Automatically Run Gated Check-in
Builds
A gated check-in build is run
automatically when either of the
following events occur:
A build has been defined with the Gated Check-in check box selected on
the Trigger tab of the build
definition.
Someone attempts to check in one or more changes that intersect with
any of the mapped folders in the
Workspace tab of the build definition.
Even if you add a ***NO_CI*** tag and try to checkin, it will stll fire the check to build changes.
The obvious workaround is of course to check the checkbox ignoring the need to do a build (a path I am sure you are trying to avoid).
If we take a look at the UI around editing a build definition, there aren't optional parameters for rules etcetera. All that matters is the mapped folders.
You can however set specific folders to not build by cloaking a workspace folder. However, if you do that, it will not pick up those files for builds at all. So if you had all your JS files in one folder and excluded it from the build using the cloaked approach builds would fail when you actually wanted to run the build.

The easiest way to test TFS2010 build template

I'm currently working on creating a build template for TFS2010 builds. However, I notice that I'm currently 'spamming' the source control with every change I make to the template (and lots more for all the fixes for those changes).
I wonder what the easiest way is to test the build templates I'm creating?
Is there a way to change the template file and custom activity dlls that doesn't involve checking them in?
I currently have a build controller and agent running on my developer machine, which I'm using to test the template (test = start a build and hope for less errors than last time).
Why is 'spamming' a problem? Anyway, I have a separate Team Project for doing this kind of work, that way I can check in to my hearts content without affecting the developers who need to have a stable build. once I've done my testing I check the template in to the team project(s) used by the developers.
I want to test my builds against the teams latest code-base without having to branch it over to a trial project.
Instead, I do the following:
Create a separate build definition called 'Infrastructure'
clone a production definition
Set the trigger on the Infrastructure build definition to manual.
Set the Infrastructure definitions permissions to allow only [Project]\Build group members to have full control of it.
keeps the notification of broken builds away from the bulk of the team).
Create a separate build process template, called 'Infrastructure.xaml'.
Point the Infrastructure build definition at the Infrastructure process template.
Now when I want to iterate on a new build feature for the team:
Check out the build process template I want to update, and lock it.
Copy the build process template I want to update overtop of the Infrastructure.xaml.
Add my build feature to the Infrastructure.xaml file, and check that in.
Use the Infrastructure build definition to test my changes.
Iterate over 3-4 until I get it right.
Complete the feature and have my changes verified by another Infrastructure team member.
Copy Infrastructure.xaml over the build process template I locked in (1) and check it in.
This still results in 'spam' in the TFS source control, but it keeps the build definition iteration out of the eyes of the team. My build process templates are located out of the main source tree (under the Build Process Templates folder, or in the branches themselves under a 'Core/Build' folder where no-one else on the team is typically paying any attention) so that the team is largely unaffected by it.
#d3r3kk: Why not just branch the template and merge changes back when ready instead of creating copies? That way you can preserve source history in a cleaner way as well.
Ideally, there should be a way to have a build process template that is in progress by having it on your local file system and pointing the build definition to it temporarily. Not sure if something like this exists in later versions of VS/TFS. I haven't seen it available via the UI anyway.

TFS 2010 Build Definition

In the TFS 2010 build definition window, under “Process” there are two required items. They are “Configurations to build” and “Projects to build”. Under projects to build, it will allow me to enter something like:
$/TeamProject/Area1/Area2/*
However, this doesn’t seem to do what I expect. The build fails because it’s looking for:
$/TeamProject/Area1/Area2/Sources/*
What I am trying to achieve by this is to build all the solutions held under this area. For example, I have:
$/TeamProject/Area1/Area2/Solution1/Solution1.sln
$/TeamProject/Area1/Area2/Solution2/Solution2.sln
$/TeamProject/Area1/Area2/Solution3/Solution3.sln
There are many more solutions than this, which is why I’m looking for a way to build all solutions under the specified path recursively. Is there a way to do this in TFS 2010?
You can modify the process template. Expand it with the Matching files (I don't have the exact naming now) activity. Add a parameter that passes the information you set in the build defintion to the MachingFiles actvity. Then pass into the build solution activity instead of the argument that you enter in the build definition the files that is found by the MatchingFiles activity.
Now add a dummy solution in the build definition for the solution to build (it is not used anymore).
See the blog post series on the build customization for more information on customizing the build process template.
FWIW,
I've got: "configurations to build" blank
and under "projects to build" I've added my solutions via the ellipsis button
I would setup mappings for
$/TeamProject/Area1/Area2/Solution1/
$/TeamProject/Area1/Area2/Solution2/
$/TeamProject/Area1/Area2/Solution3/
Then in the build definitions enter the three projects to build
$/TeamProject/Area1/Area2/Solution1/Solution1.sln
$/TeamProject/Area1/Area2/Solution2/Solution2.sln
$/TeamProject/Area1/Area2/Solution3/Solution3.sln
You can leave the configurations to build as blank, or if you want to do a certain build you can set it to (for example) something like Debug|Mixed Platforms (check your Configuration Manager... for the solutions you are building to see what is valid)
Alternatively, you can just map the following (depending on how much you have in this folder, if you have Solutions 4+ that you don't want to trigger builds on, don't do it at this level)
$/TeamProject/Area1/Area2
And have one solution which contains the Solution1, Solution2 and Solution3, and build that instead.
By default building your Solution1 which is mapped to
$/TeamProject/Area1/Area2
On a build agent with a working directory that is going to looks something like:
$(SystemDrive)\Builds\$(BuildAgentId)\$(BuildDefinitionPath)
You'll end up with it being build under
C:\Builds\1\Solution1\Binaries
C:\Builds\1\Solution1\Sources
C:\Builds\1\Solution1\TestResults
Which is why you want to make sure that your OutDir's etc are all correct and not hard coded!
If you have a look while building, you'll see the build agent populating the Sources folder, and it should (if configured correctly) put all outputs into the Binaries folder (and then copy them to the Drop Folder configured under Build Defaults in TFS.

Resources