TFS vNext Builds - Gated-Check-in Triggers cease to trigger some time after initial definition - tfs

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.)

Related

After upgrading to TFS 2017.3, web portal check ins do not kick off the gated check in build

We upgraded our TFS to 2017.3 last night, and all appears to be working as expected, except when making changes to files in the web portal.
When I click the Check In button, I get the following error:
Your check-in could not be completed because it affects the following gated build definitions. \USA\BuildDefinition To complete your check-in you will need to queue a build of the shelveset Gated_2021-02-05_10.23.14.4571;MyDomain\MyUser.
If I make the same change in visual studio, it kicks off the gated check in fine. Just not through the web portal.
Any ideas why that is?
Please try below steps to re-enable the gated check in.
Navigate to the build pipeline-->Edit-->go to Triggers tab-->Disable Gated check-in -->Save-->Enable Gated check-in-->Save again.
If above disable and re-enable the gated check-in doesnot work. Please try to re-create the build pipeline and configure the gated check-in.

TFS (Builds-Triggers) - There is impact of checking CI option and Gated Check-in option?

I don't understand why can I check this two options together because this options are not similar in their behavior.
I only want to check in the changes when the build (CI) succeeds.
What I need to do?
Have a nice day.
There is no impact between CI and Gated check-in. When you select CI, it will build whenever someone checks in code, it happens after the changes have been checked in to TFS. If you select Gated check-in, it will accept check-ins only if the submitted changes merge and build successfully, which means only the build succeeded the changes can be checked in.
By default, CI builds are not run after the gated check-in process is complete and the changes are checked in. However, if you do want CI builds to run after a gated check-in, select the Run CI triggers for committed changes check box.
Detailed information you can refer to the link below:
https://learn.microsoft.com/en-us/vsts/pipelines/build/triggers?view=vsts
Since you only want to check in the changes that builds succeed, you
should only select Gated check-in.

tfs 2015 gated check in failed

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".

Allow certain users to by-pass the gated check-in on TFS

I want to enable the gated check-in trigger for my TFS Build but also want to have a way to specify users who can commit their code directly without waiting to TFS to verify their code changes.
If you edit the "Security" of the build definition:
There is a permission you can control called "Override check-in validation by build" (or similar, I don't have TFS 2012 to hand, I'm using VSTS for the screen shots).
Grant certain people this permission and they can bypass the validation.
When they check-in code they will get the usual Gated Build prompt, but under "Show Options" there is a checkbox to bypass the validation:
By default Project Administrators and upwards have this permission.
For TFS 2015 Right click on the build definition, select security.Then change Override check-in validation by build to Allow

Stylecop Checkin Policy VS2012, TFS2010

We have StyleCop as part of the project and every time we compile, Stylecop is checking the code. But we already have 100K+ lines of code and it only grows every day. So rebuild of the solution is taking longer and longer than 20 seconds already. I think that the worst part of it is Stylecop.
So we are thinking of the way to remove StyleCop from compilation process, but have it as check-in policy for TFS. I have found 2 projects: SourceAnalysysPolicy and StyleCopPolicy. But neither seem to support VS2012 and numerous posts online suggest they do not work in VS2012.
I can slap StyleCop as a step into our build server (TeamCity), but then we'll have a lot of false failed builds - not really a solution.
I was hoping to have to force all check-ins in TFS to be gated check-ins and run stylecop there via MSBuild script: if no violations - actually check-in and pass control over to TeamCity. If there are violations - warn the developer and not check-in. But I've no idea if that is possible in TFS2010 and how to implement it.
Any other ideas?
I know it's an older post but I just released a check-in policy for Visual Studio 2013. I don't know if you already using VS2013 but take a look at this extension. If you want VS2012 support, you can add an issue. If there are enough votes I will add support for it.
https://stylecopcheckinpolicy.codeplex.com/
As a solution to this problem, we have Stylecop sitting on the build server and checking the rules on every check-in. We initially did have a lot of failed builds because of the stylecop rules, but after a while everybody learned all the rules and got used it. And last 2 months we had no failed builds because of Stylecop. So it all the matter of discipline.

Resources