How to add Builds to "Found in Build" in Azure DevOps Services

We are using Azure DevOps Services to manage Bug Reports on our product. As part of filling out a bug report, we want people to fill out the version the bug occurred in.

Question

Is the Dropdown Field "Found in Build" (Microsoft.VSTS.Build.FoundIn) get populated with Buildnumbers under Azure DevOps Services?

Setup

Azure DevOps Services has two ways to filling out this information, both seem to be related to Azure Pipelines.

1. Set up a link using the "Found in Build" link type. This works, but the interface is complicated and not intuitive.
2. Select from the Dropdown Menu also called "Found in Build", which should display a simple list of builds/versions to select from.

Since we don't have a full CI/CD setup yet, we have created a dummy pipeline for the sole purpose of creating build numbers that should then appear in the bug report form.

I have created this pipeline and ran some builds to generate build numbers. I can also select them using the link method (1.), which adds a link as expected. The dropdown method, however, does not show any build numbers:

Found in Build...

Considerations

While it is possible to use the links for linking a bug to a build, there are some things to consider

• The UI is more complex than a simple drop down
• It is not possible to make creating a link of a type mandatory
• The Links are in the Developer Section of the ticket form, which suggests that this field is not intended to be used by QA
• AFAIK, the links cannot be used in a Query

While it is possible to create a build task that fills the Found In/Integrated In dropdown with the current build, this does not add the field to the dropdown list

• There is little information on how to update fields in this way and no information so far how to add a value to a list
• The Found In / Integrated In Fields have the apperance of a dropdown, but their type seems to be String. Other Dropdowns have the "correct" Picklist type
• If a Build Number is added to one of these fields, the UI "breaks" and the field is no longer presented as a dropdown
• The field is now a string field for all bugs, regardless of contents

What I've found so far

• I have found a Blog Post from 2017 announcing the new "linking of work items", but it does not mention deprecating the other fields.

• Fields that integrate with Team Foundation Build

  • Documentation talks about Azure DevOps Server, which is the On Premise Version of Azure DevOps. It's unclear if this documentation applies to Azure DevOps
  • The Build Service seems to create a new bug when a build fails and fill these fields.
  • Azure DevOps does not fill the Integrated In Build for linked bugs when a Build succeeds. Instead, it creates a link of the same name. This seems to suggest that links are the way forward.
  • A lot of "solutions" use xml to configure fields, which only seems to apply to selfhosted Azure DevOps Server installations.

• Integrated in build field does not update on work items

  • This post on the the Microsoft Devcommunity site talks about the same problem, but with regards to the "Integrated in Build" field. Here, the answer seems to be, that this field is not used in YAML Builds.

Hi, the Microsoft.VSTS.Build.IntegrationBuild field can not be used to get the build links for VSTS, since the Microsoft.VSTS.Build.IntegrationBuild field is designed for the XAML build (not vNext build). And you can also find relation information in the blog Automatic linking work items to builds:The build fields are populated with build numbers only for XML builds. This will continue to work as is for XML builds. The new build system does not populate these fields.

---

Few things to add...

This field used to be populated when it was used as part of XML-based (XAML) "Team Build" builds. "Team Build" was replaced with web-based UI pipelines (now referred to as "Classic" which have fallen out of favour for YAML-based builds). XAML-based Team Build was slated to be removed from the product in TFS-2018 but was brought back for legacy-conversion reasons. The quote from 2019 you've referenced, highlights that this field no longer get populated:

The build fields are populated with build numbers only for XML builds. This will continue to work as is for XML builds. The new build system does not populate these fields.

Why this field continues to be a drop-down is an amusing anecdote, at best. Somewhere on the planet, someone has a TFS 2018 environment that is still using a TFS 2015 build agent that might be using a XAML-based build and maybe populating this field. Chances are: no one has noticed, no one sees this as a priority, or no one wants to be responsible for breaking compatibility on something that technically is still supported. Or maybe it's because the majority of other fields on the screen are also dropdowns and it's difficult to change?

This field remains in the UI as a text-box because it can be queried. As you've pointed out, the "Found in Build" link cannot be used in query.

Regarding the "Found In Build" link, it is automatically populated if you're using the Test & Feedback extension or when running your Test Plan manually.

The following shows that the most recent build and the Test Case that was used to discover the Bug are automatically linked when it's created through the tools mentioned above: