Skip to main content

Custom TFS Task to Change WorkItem State

I recently had to create a custom task to update the state all work items associated with a changeset were in. Here is the code I came up with to accomplish this.

First we start of by creating a general class that includes a few properties. The properties will allow us to pass in variables to the task. LocalPath and BuildURI are variables which TFS build provides for you. I also included the using statements you need to have for this task.

   1: using Microsoft.Build.Utilities;
   2: using Microsoft.TeamFoundation.Client;
   3: using Microsoft.TeamFoundation.VersionControl.Client;
   4: using Microsoft.TeamFoundation.WorkItemTracking.Client;
   5: using Microsoft.TeamFoundation.Build.Client;
   6:  
   7:  
   8: namespace MyCustomStuff.TFS.Tasks
   9: {
  10:     public class UpdateWorkItemStatus : Task
  11:     {
  12:         // A value for each one of these properties must be supplied in the XML build file. 
  13:         // LocalPath and BUILDURI can use the MSBuild variables of $(TeamFoundationServerURL) and $(BuildURI)
  14:         [Required]
  15:         public string LocalPath { get; set; }
  16:         [Required]
  17:         public string BuildURI { get; set; }
  18:         [Required]
  19:         public string NewStatus { get; set; }
  20:         
  21:         // This is the status the work item must be in for the status to be updated. This prevents us from updating all 
  22:         // workitems that where checked in associated to a buid.
  23:         public string ConditionalStatus { get; set; }
  24:  
  25:         public override bool Execute()
  26:         {
  27:            
  28:         }
  29:     }
  30: }

Now we are set up and ready to build out the task. What I wanted to do was connected to TFS and get a list of all the workitems associated with the build that was just run (this is why you have to pass in the Build URI). If you insert the follow code in the line 27 from above you get a working custom task.

   1: try
   2: {
   3:     // Get the TFS server
   4:     TeamFoundationServer server = TeamFoundationServerFactory.GetServer(LocalPath);
   5:  
   6:  
   7:     // Get the WorkItem store
   8:     WorkItemStore wiStore = (WorkItemStore)server.GetService(typeof(WorkItemStore));
   9:     //BuildStore buildServer = (IBuildServer)server.GetService(typeof(IBuildServer));
  10:     IBuildServer buildServer = (IBuildServer)server.GetService(typeof(IBuildServer));
  11:     IBuildDetail build = buildServer.GetAllBuildDetails(new Uri(BuildURI, UriKind.Absolute));
  12:  
  13:     List<IWorkItemSummary> assocWorkItems = InformationNodeConverters.GetAssociatedWorkItems(build);
  14:     EventLog.WriteEntry("UpdateWorkItemStatus", string.Format(string.Format("Found {0} workitems for Build {1} : BuildURI = {2} LocalPath = {3}",assocWorkItems.Count, build.BuildNumber, BuildURI,LocalPath), EventLogEntryType.Information));
  15:  
  16:     // Loop through each work item and update the status
  17:     foreach (IWorkItemSummary wItem in assocWorkItems)
  18:     {
  19:         WorkItem wi = wiStore.GetWorkItem(wItem.WorkItemId);
  20:         // Only update the work Item if no conditional status was provided or if the conditional status matches
  21:         if (ConditionalStatus == string.Empty || wi.State.ToLower().Trim() == ConditionalStatus.ToLower().Trim())
  22:         {
  23:             EventLog.WriteEntry("UpdateWorkItemStatus", string.Format("WorkItem {0} was updated from {1} to {2}", wItem.Id, wItem.Status, NewStatus), EventLogEntryType.Information);
  24:             // Update the state and add a note in the history stating the build process made this change.
  25:             wi.History.Insert(0, string.Format("Build process changed state from {0} to {1}", ConditionalStatus, NewStatus));
  26:             wi.State = NewStatus;
  27:             wi.Save();
  28:         }
  29:     }
  30:  
  31:     return true;
  32: }
  33: catch (Exception ex)
  34: {
  35:     EventLog.WriteEntry("UpdateWorkItemStatus", ex.Message, EventLogEntryType.Error);
  36:     return false;
  37: }

For this task I get the list of all workitems associated with the changeset and loop through that list. As I loop through I get the details for each workitem and than perform a check to see rather or not I should update the workitem. If the workitem's state matches the conditional state parameter that was passed in, than I update the workitem to the new state which was also passed in to my task. That is all there is to it. Now lets take a look at how you call it via your TFS build script.

Once you build the above code and deploy it to your build server you can call that task from any TFS build which uses that build server. To call the task you have to make a couple additions to the XML in your TFS build. First you need to add a node that says you are using a new task:

   1: <!-- This is the custom task that will update all associated work items to a new status -->
   2: <UsingTask TaskName="UpdateWorkItemStatus" AssemblyFile="$(MSBuildExtensionsPath)\MyCustomTFSTask.dll"/>

This allows the rest of your build process to now call a custom task of "UpdateWorkItemStatus." The $(MSBuildExtensionsPath) is a global parameter in TFS build and is for the MSBuild folder under the Program Files directory. This location is a useful place to put custom target files (For example, your targets files could be installed at \Program Files\MSBuild\). Now all you need to do is call the task after the build is done. To do this you would think you could use the "AfterBuild" target but you cannot (at least I have never gotten it to work). You actually need to use the "TeamBuild" target. This target is fired off after the build has completed and can be called with the follow XML.

   1: <Target Name="TeamBuild" Condition=" '$(IsDesktopBuild)'!='true' "
   2:           DependsOnTargets="$(TeamBuildDependsOn)">
   3:     <Message Text="TeamBuild is firing!"/>
   4:     <!-- Now update all associated work items to the right status -->
   5:     <UpdateWorkItemStatus NewStatus="Sys Test" LocalPath="$(TeamFoundationServerUrl)" BuildURI="$(BuildUri)" ConditionalStatus="Dev Complete" />
   6:  
   7:  </Target>
This is where you declare the value of all your parameters. Now each time at team build fires off any associated workitem that is a match will be updated.

Comments

Thank you for posting this article. I am also working on Team foundation server, I am using its reporting part.So sharing my knowledge:
You can add your own custom report.Reports that you view opened in read only mode. Reports generated by this software helps you easily access the status of the team project.

Popular posts from this blog

Uniting Testing Expression Predicate with Moq

I recently was setting up a repository in a project with an interface on all repositories that took a predicate. As part of this I needed to mock out this call so I could unit test my code. The vast majority of samples out there for mocking an expression predicate just is It.IsAny<> which is not very helpful as it does not test anything other then verify it got a predicate. What if you actually want to test that you got a certain predicate though? It is actually pretty easy to do but not very straight forward. Here is what you do for the It.IsAny<> approach in case someone is looking for that. this .bindingRepository.Setup(c => c.Get(It.IsAny<Expression<Func<UserBinding, bool >>>())) .Returns( new List<UserBinding>() { defaultBinding }.AsQueryable()); This example just says to always return a collection of UserBindings that contain “defaultBinding” (which is an object I setup previously). Here is what it looks like when you want to pass in an exp

Password Management

The need to create, store and manage passwords is a huge responsibility in modern day life. So why is it that so many people do it so poorly? This is a loaded questions with answers ranging from people being uneducated, to lazy, to educated but not affective in their methods and many more. This blog is to help those (in some way even myself) around me strengthen their online security. Why does it matter? To answer this let's look at a few numbers. According to the US Department of Justice (DOJ)’s most recent study , 17.6 million people in the US experience some form of identity theft each year. Ok fine but that is identity theft that has nothing to do with password management. What is one way someone can start getting information about who you are? How do they get access to steal your money? From Cyber Security Ventures 2019 report : "Cybersecurity Ventures predicts that healthcare will suffer 2-3X more cyberattacks in 2019 than the average amount for other industries. W

Experience Profile Anonymous, Unknown and Known contacts

When you first get started with Sitecore's experience profile the reporting for contacts can cause a little confusion. There are 3 terms that are thrown around, 1) Anonymous 2) Unknown 3) Known. When you read the docs they can bleed into each other a little. First, have a read through the Sitecore tracking documentation to get a feel for what Sitecore is trying to do. There are a couple key things here to first understand: Unless you call " IdentifyAs() " for request the contact is always anonymous.  Tracking of anonymous contacts is off by default.  Even if you call "IdentifyAs()" if you don't set facet values for the contact (like first name and email) the contact will still show up in your experience profile as "unknown" (because it has no facet data to display).  Enabled Anonymous contacts Notice in the picture I have two contacts marked in a red box. Those are my "known" contacts that I called "IdentifyAs"

Anatomy of Sitecore Business Rule - Macros

In previous posts, we talked about  field syntax and the basic structure of business rules . This time we are going to dive into macros in the business rules. Macros are used as part of the business rule syntax. The syntax looks like this and calls for 4 parameters. [Property to set, Operator/Macro, AdditionalParameters, Display text]. When I first started working with business rules the difference between operator and macro was confusing. To add to this confusion some of the out-of-the-box macros are named with the term "operator" (like ListOperator who's configuration points to a class called ListMacro and the class implements IRuleMacro). Anything under the path /sitecore/system/Settings/Rules/Definitions/Macros should be a macro and should implement IRuleMacro. Macros have the follow characteristics: They inherit the IRuleMacro interface The interface requires this execute method void Execute(XElement element, string name, UrlString parameters, string value)

Excel XIRR and C#

I have spend that last couple days trying to figure out how to run and Excel XIRR function in a C# application. This process has been more painful that I thought it would have been when started. To save others (or myself the pain in the future if I have to do it again) I thought I would right a post about this (as post about XIRR in C# have been hard to come by). Lets start with the easy part first. In order to make this call you need to use the Microsoft.Office.Interop.Excel dll. When you use this dll take note of what version of the dll you are using. If you are using a version less then 12 (at the time of this writing 12 was the highest version) you will not have an XIRR function call. This does not mean you cannot still do XIRR though. As of version 12 (a.k.a Office 2007) the XIRR function is a built in function to Excel. Prior version need an add-in to use this function. Even if you have version 12 of the interop though it does not mean you will be able to use the function. The