Summary
Azure DevOps work items in the Removed state (explicitly abandoned/cancelled) currently appear in BuildMark build notes. This is misleading — a Removed item is one the team has decided no longer exists.
Current Behaviour
Known Issues: The \IsWorkItemResolved\ check in \WorkItemMapper\ recognises \Resolved, \Closed, and \Done\ as terminal states, but not \Removed. A Removed bug without \affected-versions\ set will therefore be included as a known issue.
PR-linked Changes: \ProcessLinkedWorkItems\ performs no state check at all. A work item linked to a PR that is subsequently moved to Removed will appear as a delivered change.
Requested Behaviour
Work items in the \Removed\ state should be suppressed from all sections of the build notes — both changes and known issues — as if they do not exist.
Rationale
"Removed" in Azure DevOps is an explicit abandonment state. Surfacing these items in build notes is misleading:
- In Changes: implies work was delivered on something that was discarded.
- In Known Issues: implies there is an open bug that has actually been abandoned.
Suggested Implementation
Add "Removed"\ to the suppressed/excluded states in \WorkItemMapper, ideally as an early-exit
ull\ return in \MapWorkItemToItemInfo\ so both code paths are covered with a single change.
Summary
Azure DevOps work items in the Removed state (explicitly abandoned/cancelled) currently appear in BuildMark build notes. This is misleading — a Removed item is one the team has decided no longer exists.
Current Behaviour
Known Issues: The \IsWorkItemResolved\ check in \WorkItemMapper\ recognises \Resolved, \Closed, and \Done\ as terminal states, but not \Removed. A Removed bug without \affected-versions\ set will therefore be included as a known issue.
PR-linked Changes: \ProcessLinkedWorkItems\ performs no state check at all. A work item linked to a PR that is subsequently moved to Removed will appear as a delivered change.
Requested Behaviour
Work items in the \Removed\ state should be suppressed from all sections of the build notes — both changes and known issues — as if they do not exist.
Rationale
"Removed" in Azure DevOps is an explicit abandonment state. Surfacing these items in build notes is misleading:
Suggested Implementation
Add "Removed"\ to the suppressed/excluded states in \WorkItemMapper, ideally as an early-exit
ull\ return in \MapWorkItemToItemInfo\ so both code paths are covered with a single change.