What should you do if you see the error “TF42097: A work item could not be created due to a field error” under the Other Errors and Warnings section of a failed build? The error may seem mysterious initially, because it’s a build complaining about a work item and the connection is not obvious.
The explanation is quite straightforward: the build uses the Default Template (or a derivative) and has the Create Work Item on Failure option turned on, however the Bug work item has been modified in a way that means the build is unable to create it – which could be as simple as making a field mandatory. When I saw this error it was due to putting a work around in place to force users to choose an Area, but the build template left the Area as the default – which was prohibited.
How you fix this depends on how the Bug work item has been restricted. Work item fields that have been made mandatory should have a value specified in the build process template, and if that value should vary depending on the build definition you will need to expose it as an argument in the definition. Here is a step-by-step guide:
- Open the build process template you are using (if using the Default Template it is recommended that you make a copy and point your build definitions to it before modifying it).
- Click the Arguments tab at the bottom
- Create a new argument for each mandatory field in the Bug work item that should have a different value depending on the build definition. Then edit the Metadata argument to make the new argument(s) user friendly in the build definition (optional!)
- Find the place in the build definition where the work item is created. This is hidden very well but you can find it here in the Default Template: Sequence –> Run on Agent –> Try Compile, Test, and Associate Changesets and Work Items –> Sequence –> Compile, Test, and Associate Changesets and Work Items –> Try Compile and Test –> Compile and Test –> For Each Configuration in BuildSettings.PlatformConfigurations –> Compile and Test for Configuration –> If BuildSettings.HasProjectsToBuild –> For Each Project in BuildSettings.ProjectsToBuild –> Try to Compile the Project –> Exception –> Handle Exception –> If CreateWorkItem –> Create Work Item for non-Shelveset Builds –> Create Work Item
- Open the Properties for the Create Work Item activity and expand the Custom Fields property. Thankfully this is just a Dictionary of key-value pairs and quite easy to edit. Before the final closing brace just add additional pairs of work item field reference names and the value they should have. If you need to pass through the value of an argument you may find this a little tricky – all the braces and escaping in the underlying XML make it difficult to pass in arguments normally so you may need to wrap them in a String.Format(“{0}”, MyArgument) statement.
My final OpenWorkItem activity looked like:
<mtbwa:OpenWorkItem AssignedTo="[BuildDetail.RequestedFor]"
Comment="["This work item was created by TFS Build on a build failure."]"
CustomFields="[New Dictionary(Of String, String) From { {"System.Reason", "Build Failure"},
{"Microsoft.VSTS.TCM.ReproSteps", "Start the build using TFS Build"},
{"Microsoft.VSTS.CMMI.Symptom", "Build Failure"}, {"Priority", "1"},
{"Severity", "1 - Critical"}, {"Microsoft.VSTS.CMMI.FoundInEnvironment", "n/a"},
{"System.AreaPath", String.Format("{0}", WorkItemArea) }, {"MyCo.Client", "n/a"},
{"MyCo.Project", "BAU"} }]"
DisplayName="Create Work Item" Title="[String.Format("Build Failure in Build: {0}", BuildDetail.BuildNumber)]"
Type="["Bug"]" />
<pre>
There’s a lot of escaping to make it valid XML so it’s best to edit in the designer!
Comments