I created a ci build in tfs 2015.3. On the trigger tab I set gated check in.
Is there a way to let the developer now in vs that the build failed. Currently there is no way, I do not want to use alerts, I would like for a message in vs.
In addition, when the build fails, the files are checked out on the build server, how can I cancel this behavior, this requires a tfs admin to release the files.
In TFS 2013 there used to be a tool called Team Foundation Build Notification that shipped with Visual Studio 2013. However this is no longer the case.
If you don't want to use e-mail notifications there are third party applications that you can run in your tray to receive build notifications. I have used catlight myself recently for the exact same problem. If you are using a chat application like Slack you can also integrate build notifications into your team's slack channel to be notified on build failure.
To answer the second part of your question it is important to understand what a gated check-in does exactly.
When you check-in and a gated check-in is triggerd your files are not checked in but TFS creates a shelveset instead. TFS will then perform a private build using the latest version of the sources in combination with the shelveset it just created. Only when the this private build passes the pending changes in your shelveset will be checked in by the build on behalf of the user who triggerd the gated check-in. This will create a new changeset.
Upon check-in all locks will be released so all files that have a check-in or check-out lock will be released when the build server checks in your changes on behalf of you.
When the build fails no the changes in the shelveset (created when the gated check-in build was triggerd) will not be checked-in by the build server thus the locks will not be released. In the source control explorer the files will still have pending changes (and be checked-out) because the changes in your workspace have not yet been checked-in. This is the intended beheaviour and should not cause any issues for you unless you have disabled multiple check-out and you are, by having these files checked-out, blocking other developers from making changes.
I would not advise you to use a gated check-in when also not allowing multiple check-outs. Furthermore I would not advise disallowing multiple check-outs if it can be avoided in any way.
A gated check-in is meant to safeguard the repository from receiving check-ins that would break the application (it no longer compiles or unit tests fail) or diminish the quality below your standards. However this also means you cannot check-in until all the rules and validations you have in your build process pass and thus means other developers will be locked out until you are able to get past the "gate".
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've defined several Build Definitions using the TFS vNext build system. These include use of the Gated Check-In feature.
Initially, when the builds are defined, check-ins that have files that fall within the path of any of the Include sections of the Gated Check-in filters cause the prompt for the Gated Check-In to appear, followed by (upon acceptance) the triggering of the build.
However, after some time (e.g. 1 day), check-ins from some developers no longer trigger the Gated Check-in (and submissions are committed immediately to source control), while check-ins from other developers continue to cause the Gated Check-In prompt to appear.
I'm unable to reset this by just unchecking;saving;re-checking the Gated Check-in checkbox.
As a work-around, I have been able to enable the gated check-in for the same paths on a different build, then undo it, and re-enable on the original build. This only works for a short time, however.
I've seen this in both the TFS Server 2015 Update 2 and Update 3.
This problem never occurred with the old XAML builds.
The server product/version is:
Microsoft Visual Studio Team Foundation Server Update 3
Version 14.95.25122.0
How can I configure TFS vNext check-ins so that they're always fired?
Keywords:-
Gated check-in failure; Gated check-in doesn't fire; Gated check-in skipped
This is a TFS bug.
After logging a support case with Microsoft, they confirmed that this is a TFS bug that occurs on TFS installations that have multiple TFS Application Tiers (ATs) configured through a load balancer.
In some cases, the TFS vNext Build Gated Check-Ins skip the verification and commit the changes immediately.
There is a hot-fix DLL available (for file Microsoft.TeamFoundation.Build2.Server.dll), but it requires contacting Microsoft to obtain it. Given that this is a bug, it shouldn't be a chargeable Microsoft Support incident. (I used one of my MSDN Microsoft support credits, but it wasn't deducted.)
We have a team alert in TFS 2015 that sends an email out to all developers whenever one of our builds fails.
I'd like to modify it to not issue emails when someone fails a private build, or a private gated check-in fails (we don't use gated check-ins by default). In these cases, a separate alert will issue to just the individual developer.
Below is the current criteria
However, when I tried to run a manual gated check-in just now, the build failure issued an email to the entire team.
What additional conditions are required to ensure that these emails are not generated when I create a build using a shelveset - whether or not I choose to automatically commit the changes on success.
There is no private gated check-in build, "gated check-in build" is not Private build.
You queue a private build if you want to build the changes that you
have put into a shelveset.
More detail info with private build in TFS, please refer this MSDN link:
Queue a build
When you are going to use the private build and not issue emails when someone fails, you can add a build reason not contain check in shelvest as a workaroud.
The part above your screen shot is the part that identifies if the alert is being configured for a Team (sends to everyone) or a personal alert (just to you).
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'm trying to set up our TFS 2008 instance to require that projects build before they can be checked in.
I have created a check-in policy using the out of the box "Builds" policy, but I'm still able to check broken projects in after mangling the code and attempting to build the project.
We're a small shop, and TFS was originally set up with our team's Active Directory group listed as TFS admins. Is this the problem? Do check-in policies apply to TFS admins?
Any other suggestions?
Check-in policies are a client-side check only. If the client does not have the check-in policy available, the check will not run. Instead, they will get a generic policy failure saying that not all policies were run. Additionally, any user (there's no special permission for it) can override a check-in policy failure with a comment.
The "Builds" check-in policy does the following:
Request from the server a list of build definitions affected by this check in
For each build definition returned where the last build was not "good," create a checkin policy error message containing the build definition's name and the user that triggered the build.
If the policy detects a broken CI build, show an error when you attempt to check in. "The last build failed.."
It sounds like you're trying to make sure that people don't break the build with their check-ins. TFS2010 includes a new feature called Gated Check-In that validates changes before they are committed to source control.
If you are using TFS2008 and can't upgrade, you'll need to look at something like OpenGauntlet - however the user experience is much improved with TFS2010.
TFS was originally set up with our
team's Active Directory group listed
as TFS admins. Is this the problem?
This is probably not the best idea. Team Foundation Server Administrators can do destructive things like destroy files+history and delete projects. If there's any chance that somebody might become disgruntled, you might want to reduce the number of admins or ensure that you have good backups.
As a middle-ground, you could have 1 or 2 people as TFS Admins, and everybody else as a Team Project Administrator. Most people only need Contributor access though.
In TFS2010, there is a new concept called "Project Collections". Typically, organizations have 1 or 2 people as "Project Collection Administrators" so they can add new projects and build controllers.
Check-in policies apply to everyone. Did you verify that your deployment of the policy is active on all machines?