I'm trying to get a VCS trigger to work in TeamCity with TFS but no matter what I do, I can't get it to trigger on a checkin
I've defined the VCS trigger as +:fodl/FODL.Database.InvestmentDataMart.APTExtract/**
..which I believe should only trigger a build if changes are detected in that directory but none of the pending changes every seem to trigger a build
Here's a screenshot of my build trigger:-
And a screenshot of my build source directory where all files have been checked out to:-
Does anyone know what I'm doing wrong? I can't use checkout rules to target just the FODL.Database.InvestmentDataMart.APTExtract folder as all the solution files all live in the base directory above it (FODL)
Try +:**/fodl/FODL.Database.InvestmentDataMart.APTExtract/**. If the disconnect is "where I think the root directory is" versus "where TC thinks the root directory is", the prepended wildcard should fix it.
I am not sure if this is obvious or not, but the VCS trigger only let's you control if the build will run and what rules will trigger the build. The VCS trigger does not do anything if TeamCity is not aware of the change in the source control repository. For that you need to either
Define a scheduled trigger that will change for changes in your source repository.
Or configure TFS to notify TeamCity (through web hooks or other kind of integration) that there is a change.
Related
My scenario is as follows:
Developers check-in SQL changes to directory ClientDB
A dedicated build wakes up, extracts the metadata from the checked-in files, processes it and checks the result in into a sibling directory ClientMetadata
(Developers are not allowed to check-in under ClientMetadata)
The annoying side effect, is that because the dedicated build is a CI build it wakes up twice:
Once for the changes in ClientDB, which makes it update ClientMetadata
Second time, because of its own changes in the ClientMetadata - after all, this directory appears as an Active directory in the Source Settings section of the build:
Ideally, I would like the ClientMetadata directory to be available in the workspace, but I do not want changes there to trigger the build.
Is it possible?
If the 2nd checkin from the build is done with a checkin comment that has the text ***NO_CI*** at the end, the continuous integration trigger will be suppressed.
It's a hack, but it's how gated checkins work OOTB with TFS.
What does ***NO_CI*** stand for?
Not with XAML build. It's absolutely possible in the build system introduced in TFS 2015.
When you select this trigger (CI) whenever someone checks in code, the build will run.
Actually check in files to source control during a build pipeline is not a recommended suggestion.
If you don't want to cloaked the ClientMetadata folder and still want this be pulled down on build agent during get source. Please try below workaround:
You could remove the active status for this folder and add a customize activity to only get files from TFS server path($/../../ClientMetadata) to the agent $(BuildDir).
Our builds generally have a mish mash of work items and commits associated with them and I cannot tell how TFS determines what to add. We are using TFS 2015 update 3 and TFVC.
When a build runs, it gets code from a location somewhere in the branching and folder of TFVC. Typically, something like "root\dev\src\component name" in this way we avoid getting all of the code in our repository and we have CI set up to run so that any changes in this folder will result in a CI build running.
We also run daily builds which run more tests and create a release package that is used by TFS Release Management. I would expect that any changes to code inside of the folder defined in setting up the repository for this build to be included in the associated change-sets of a build. I also expect that any changes checked-in outside of these branches would not be associated. But this is not the case. We see commits from across the entire project.
Does anyone know how this is supposed to work?
I am not sure if this should go in the question or the answer but I have found some additional information, thanks to the hints provided in the answers below.
It appears that the source settings will take the common root between mapped folders of the repository settings, so if I have 2 folders $/Relo/Dev/B1/src/Claims.Services and $/Relo/Dev/B1/src/PSScripts it will take the common root $/Relo/Dev/B1/src as the source settings and include any changes from that folder down within the build. Can anyone confirm this? Of course thats not what I want to have happen. In the History tab of the build definition if I looked at the diff I can see a field "defaultBranch" in the json which seems to be the value that controls this, is there any way to update this field directly?
TFS determines what changesets should be mapped to a build based on the Source Repository Mappings (Build vNext) in the build definition and the last successful build.
So, you will see a list of the changesets with files committed in the lowest common base of any of the mapped folders including all their descendents, since the latest successful build. Whenever you get a successful build (I hope that it happens more often than failing ones ;-)) the list will shorten and only show the last check-in.
Example mappings below will result in any changeset made to anything below $/Relo/Dev/B1/src (because it is the lowest common base):
$/Relo/Dev/B1/src/Claims.Services
$/Relo/Dev/B1/src/PSScripts
Similar it will pick up all the related work items to the above changesets.
This is what should happen. If you see something else, I would have a closer look at the Repository Mappings or Source Settings of the build definition.
#Noel - I guess you are using vNext build and not XAML builds. Or are you using a mix of XAML and vNext?
In general a scheduled TFS build will associate all changes which were not associated in the last successful run of the same build.
I suggest you check once again if the source folder locations are the same for CI build and Daily build?
We have a Visual Studio solution containing about a dozen class library projects. They're our team's main internal framework. In Jenkins we would like to automate the building of these projects as soon as a check-in is made, and also publish a new version to our local NuGet repo.
The problem: We would like to trigger the build by polling SVN at the class library level, e.g. ..trunk/OurSolution/OurCoreProject. Changes in one project should not trigger a build on all the other projects. But the checkout needs to be done one level higher, e.g. at ..trunk/OurSolution, and I cannot figure out how this can be done.
We've tried and contemplated a few solutions already:
Checking out at project level and then send the .csproj file to
MsBuild.exe instead of the .sln file. This fails because the project
expects a sibling folder named .nuget.
Looking into the Multiple SCMs
plugin, but it seems to mainly add the ability to use different SCM
providers in the same project(?) I would like to avoid adding this
plugin until I know it solves this.
Splitting all the projects up into separate solutions. Doesn't feel very optimal...
Is there a way to solve this in Jenkins? Have a missed any viable solution?
Yes you have missed something... the Advanced... button on the Subversion checkout configuration.
Do your SVN checkout on ..trunk/OurSolution
Click Advanced...
Under Included Regions, type ..trunk/OurSolution/OurCoreProject/*
For more info, click the ? icon next to relevant text area on the UI
If set, and Jenkins is set to poll for changes, Jenkins will ignore any files and/or folders that are not in this list when determining if a build needs to be triggered.
Is it possible programmatically to on a Gated -Check in build in TFS 2010 to not trigger a Gated Build when checking in a specific file type, i.e. ".config"? How can I accomplish that?
Not that I know of, you can only configure the workspace mappings which controls when the build triggers. so you can include or cloak folders, but not file types.
Presumably you don't want to run the Gated Build because a config file won't affect the build. But still running the build anyways shouldn't really hurt anything, you just waste a little bit of resources on your build server.
If it's really a concern, you can customize the build template, to look at what files are in the linked changeset (using a custom activity and the TFS API probably), and if it's just config files abort the build (with a successful result).
I would go down the route of seeing what messages TFS processes when performing a gated checkin. It might be possible to some how write a TFS server side plugin to hook the event, inspect the changeset and stop the build while allowing the shelf set to commit.
You are swimming pretty far out of Microsofts swim lane on this one so I'm not sure how much work and what the side effects would be on this one.
FWIW, I would want the build to run even on a config file change because I always want to be able to deploy the latest build and see the state of my project.
I maintain our build process on our TFS 2012 system.
Up till now I've been making changes locally to a solution that generates our custom activity DLLs. These DLLs are checked into TFS and are used by the build controllers and agents for the custom activities in our custom build template.
For all of my code and workflow activities I have a unit test library that I can locally run to put in some base test values. While this gives me a good idea at how my custom tasks will run it is not optimal.
What I would like to be able to do is run the entire build definition. Is there a way to test the whole build process locally so that I can be sure that my changes to the workflow are acceptable before checking in and kicking off a build? Right now my builds take between 30 and 40 minutes to complete and I would like to be able to start, monitor, debug, and stop the build locally without occupying one of our agents.
Edit
Another method for me to solve this problem is to come up with some manner to execute the workflow that is the build template locally. Has anyone been able to do this?
Take a look at the Ranger Build Customization Guidance. There is a HOL for doing a lot of this. It doesn't look like it is in v2 so take a look at v1.2.
http://vsarbuildguide.codeplex.com/releases/view/87995
If I am understanding the issue correctly, one way to do this may be:
Install a build agent locally and register it with the TFS Build Controller.
Give the new agent a custom tag so it doesn't get assigned other builds from the queue
Shelve your changeset
In VS, right click the build definition you want, and select queue new build. A "Queue Build" window will open
Under the general tab, "What do you want to build", select your shelveset.
Under Parameters tab ->Advanced -> agent settings, enter your agent's tag.
Click queue.
I accomplish this using a modified version of #malexander recommendation.
Create a code branch in TFS, commit your changes there, especially the changes to your custom activity DLL's (compiled binaries, not just source).
Install a TFS Build Controller and Build Agent locally, registering the controller with your TFS server.
Configure your new local controller to use your modified custom activity DLL's, stored in your new TFS code branch. Team Explorer > Builds > Actions > Manage Build Controllers >
(select your new local controller) > Properties > Version control
path to custom assemblies
4.
Queue a new build, from an existing TFS build definition: change its controller to use your new local controller.
The new build will execute on your local controller/agent, using your modified custom activity DLL's, without interfering/restarting your production agents.
Also: since you're in your own code branch, you can commit debug versions of your custom activity DLL's, without impacting your production agents.