ADO connector: known issues queried at project scope instead of repository scope

[Malcolmnixon]

Summary

When using BuildMark with an Azure DevOps connector where the ADO project contains multiple repositories, the known-issues query returns all open work items across the entire project rather than scoping them to work items linked to the configured repository.

Environment

• BuildMark version: 1.2.1
• Connector: azure-devops

Steps to Reproduce

1. Configure .buildmark.yaml\ with an Azure DevOps connector pointing to a project that contains multiple repositories/products:

\\yaml
connector:
type: azure-devops
azure-devops:
url: https://dev.azure.com/myorg
project: MyProject
repository: MyRepo
\\

2. Run \dotnet buildmark --report report.md --build-version 1.0.0\

Expected Behaviour

Known issues should be scoped to work items that are linked to commits within the configured repository (\MyRepo). Work items from other repositories or products within \MyProject\ should not appear.

Actual Behaviour

The console reports a large number of known issues (e.g. hundreds) sourced from the entire \MyProject\ ADO project — including work items from completely unrelated repositories and products that predate the creation of the configured repository.

These known issues are then passed through the routing rules (e.g. \work-item-type: [Bug] → bugs-fixed) and appear in the generated report under sections such as ## Bugs Fixed, making it appear as though the repository fixed hundreds of bugs from other products.

The console output distinguishes \Bugs Fixed: 0\ (correct — no work items linked to commits in range) from \Known Issues: N\ (incorrect — project-wide rather than repository-scoped), but the report renders the known issues under the routed sections regardless.

Suggested Fix

The ADO known-issues query should be filtered to only return work items that are linked to commits within the configured repository. This could be achieved by:

• Querying work items via the ADO commit→work-item link API scoped to the specific repository, or
• Adding an optional \�rea-path\ filter to the \�zure-devops\ connector configuration to allow users to manually scope the query as a workaround.

[Malcolmnixon]

Testing the Fix (BuildMark 0.0.0+e11e212)

Tested the fix against an on-premises Azure DevOps Server instance where the ADO project contains multiple repositories.

New Issue: Crash on 400 Bad Request

The fix introduces an unhandled exception crash when the default {project}\{repository} area path does not exist in the ADO project:

Unexpected error: Response status code does not indicate success: 400 (Bad Request).
Unhandled exception. System.Net.Http.HttpRequestException: ...
   at AzureDevOpsRestClient.QueryWorkItemsAsync(String wiql)
   at AzureDevOpsRepoConnector.CollectKnownIssuesAsync(...)

WIQL query tests confirm the cause:

• WHERE [System.WorkItemType] = 'Bug' → 200 OK
• WHERE [System.WorkItemType] IN ('Bug', 'Issue') → 200 OK (IN operator works fine on this server)
• WHERE ... AND [System.AreaPath] UNDER 'MyProject\MyRepo' → 400 Bad Request (area path does not exist)

Root Cause

The fix defaults effectiveAreaPath to {project}\{repository} and applies [System.AreaPath] UNDER '...' in the WIQL query. However many ADO projects — particularly on-premises installations — do not follow a per-repository area path convention. When the area path does not exist, ADO returns 400 rather than empty results, crashing the tool.

In the tested project the area hierarchy is completely flat with no per-repository sub-areas, so no area-path value can be configured that would scope to a single repository.

Suggested Improvements

1. Handle the 400 gracefully: Catch the 400 from the WIQL endpoint and surface a clear message (e.g. Area path 'X\Y' does not exist — set area-path in .buildmark.yaml or use empty string to query project-wide) rather than an unhandled exception crash.

2. Consider a repository-native scoping mechanism: Area paths are a team/process concept and may not map to repository boundaries. An alternative approach would be to scope known issues by querying work items linked to commits within the repository's git history, which is inherently repository-scoped and does not depend on the ADO area hierarchy.

[Malcolmnixon]

Second Issue: Known Issues rendered into Bugs Fixed section

On further analysis, the original report output is misleading in a more fundamental way.

BuildMark runs two independent queries:

1. Commit-linked items — work items associated with commits between the previous version tag and HEAD. This correctly returns 0 for a repository where no commits have linked work items.
2. Known issues — a separate project-wide WIQL query for open bugs, entirely independent of the repository's commit history.

Both result sets are passed through the same routing rules (e.g. Bug → bugs-fixed) and rendered into the same report sections. The console correctly reports Bugs Fixed: 0 and Known Issues: 735, but the report renders all 735 project-wide open bugs under ## Bugs Fixed — making it appear as though the build fixed hundreds of unrelated bugs from other products.

The commit-range is the contract for what constitutes a change in a given build. Known issues that have no linked commits in that range should either:

• Be rendered in a clearly separate section (e.g. ## Known Issues) so they are never confused with bugs that were actually fixed, or
• Not appear in the report at all unless the user opts in via a flag (--include-known-issues already exists for this purpose — perhaps known issues should be opt-in rather than always-on)

As it stands, the combination of a project-scoped known-issues query and rendering them under fix sections produces build notes that are actively misleading.