A Gated Check in with an induced Build "Failure" : the Code Still Commits :(

Question

Short Version:

I am setting the Status=Failed and TestStatus = Failed on a custom build template (.xaml). When the build is setup as a Gated Check In (CheckIn), the code still commits.

Long Version:

I have some custom logic in the build workflow that is setting the below properties.

<!--the below is a result if a custom code activity I wrote returns a "true" for Code Coverage being lower than expected  -->
<mtbwa:SetBuildProperties DisplayName="Set Status and TestStatus to Failed" Status="[Microsoft.TeamFoundation.Build.Client.BuildStatus.Failed]" TestStatus="[Microsoft.TeamFoundation.Build.Client.BuildPhaseStatus.Failed]" sap2010:WorkflowViewState.IdRef="SetBuildProperties_7" />

My build "goes orange", but the code still gets checked in. The check-in of the code is the undesired result.

Some other "setup" screens:

Other articles I found:

TFS Gated check-in -- How to reject check-in on Partial Build Success?

Fail a build if code coverage is below a threshold in TFS2012

APPEND:

My template was from a Microsoft default one.

My custom check is defined between

If CompilationStatus = Unknown

and

If TestStatus = Unknown

And what does the check around the Check-in shelfset look like? I suspect it may just be specifically looking at the Compilation Status — jessehouwing, Mar 11 '16 at 16:31
Originally I had set the CompiliationStatus to failed.....but I'll look deeper at your suggestion. — granadaCoder, Mar 11 '16 at 16:33

score 1 · Accepted Answer · edited Mar 11 '16 at 20:12

At the end of the workflow there should be a task that checks in the shelfset. Make sure that is encapsulated in the proper logic to skip the checkin when the compilation status, test status or overall build status isn't what you want.

Original Gated Checkin might look like this:

<mtbwa:InvokeForReason DisplayName="Check In Gated Changes for CheckInShelveset Builds" sap2010:WorkflowViewState.IdRef="InvokeForReason_6" Reason="CheckInShelveset">
  <mtbwa:CheckInGatedChanges DisplayName="Check In Gated Changes" sap2010:WorkflowViewState.IdRef="CheckInGatedChanges_1" />
</mtbwa:InvokeForReason>

With an IF condition around it:

<If Condition="[BuildDetail.TestStatus = Microsoft.TeamFoundation.Build.Client.BuildPhaseStatus.Succeeded]" DisplayName="BuildDetail.TestStatus = Microsoft.TeamFoundation.Build.Client.BuildPhaseStatus.Succeeded" sap2010:WorkflowViewState.IdRef="If_41">
  <If.Then>
    <mtbwa:InvokeForReason DisplayName="Check In Gated Changes for CheckInShelveset Builds" sap2010:WorkflowViewState.IdRef="InvokeForReason_6" Reason="CheckInShelveset">
      <mtbwa:CheckInGatedChanges DisplayName="Check In Gated Changes" sap2010:WorkflowViewState.IdRef="CheckInGatedChanges_1" />
    </mtbwa:InvokeForReason>
  </If.Then>
  <If.Else>
    <mtbwa:WriteBuildWarning DisplayName="Write BuildDetail.TestStatus" sap2010:WorkflowViewState.IdRef="WriteBuildWarning_5" Importance="[Microsoft.TeamFoundation.Build.Client.BuildMessageImportance.High]" Message="[&quot;Gated Checkin Failed, BuildDetail.TestStatus=&quot; &amp; System.Enum.GetName(GetType(Microsoft.TeamFoundation.Build.Client.BuildPhaseStatus), BuildDetail.TestStatus)]" mva:VisualBasic.Settings="Assembly references and imported namespaces serialized as XML namespaces" />
  </If.Else>
</If>

Note. The BuildStatus will be set back to "InProgress" by TFS. Piggyback on BuildDetail.TestStatus is probably the better bet.

I took liberty to edit/append your answer for future readers. Marked as answer as you got me over the "d'oh" moment. Thx. — granadaCoder, Mar 11 '16 at 20:13

A Gated Check in with an induced Build "Failure" : the Code Still Commits :(

1 Answers1