I am using TFS Gated checkins. I have noticed that every time a javascript file is checked-in, it also triggers the build and it wastes a lot of time.
How can I prevent a build being triggered if a javascript file (or other similar file types) is checked in?
You have two choices:
Cloak the folder containing your JS file. If possible, set the Workspace (Source Settings in the Build Definition) to Cloak the path to the file(s) you don't want to trigger a build. This is not possible for a particular file extension though, just paths.
When you check in a JS file, add ***NO_CI*** to the end of the check in comment. This prevents a build from triggering.
Or a third choice (not a real option, but I'll put it here just for completeness): If you have permissions on the build to override the gated build, you can just tick the box and bypass the gated build.
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).
I have two build definition "A" and "B". I marked "A" to be triggered (Gated Check-in) when the check in include files under "src\ProjectA" and "B" to be triggered when the check in include files under "src\ProjectB".
It's working as expected when the chech-in include only one of the folders.
When the check-in include both of the folder and I click the CkeckIn button in Visual Studio I have to select which build I want to run (I choose "A") and only this build running and all the files are getting in, meaning that some code get into the repository that can break the build that didn't run ("B").
How can I make TFS run both builds whenever such a checkin will be delivered and not accept the change if all of the depended build get passed?
Each gated check-in build definition can have only one running build at a time. If you have two build definitions configured for the same source control folder then you will always get a choice. Your situation is very likely configured for the same source control folder.
It is recommended to have only check in each Project fold instead of check in include both of the folder together to avoid confusion. As a workaround you could first check in files in folder src\ProjectA and then exclude others, after the gated check-in build completed, include other files again.
For more info of the TFVC gated check-in, you could take a look at James Reed's answer in this question Can we build multiple gated check-ins in parallel?
I have a large solution. I want the ability to do gated check in on one specific file. I.e if I do check in on this specific file (that file could impact on all the solution) all the solution will build (gated check in), but if I'll do check in on another file it will do regular check in, without build.
Thank you
It is not possible to configure this out of the box. You can have Gated checkin or not configured at the solution. It will trigger based on the scope of the path configured for source.
You could create an ISubscriber event in code that checks each checkin for the offending file and kicks off a build if it is detected.
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.
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.