mirror of
https://github.com/renovatebot/renovate.git
synced 2026-11-06 20:20:44 +00:00
Emanuel Besliu
483890a8f1
* fix(platform/azure): resolve work item states from process Renovate hardcoded the Azure Boards work item state to `New` on create/reopen and `Closed` on close. Processes that don't have those states (Basic uses To Do/Done; custom inherited processes vary) reject the request with "The field 'State' contains the value 'New' that is not in the list of supported values", so the Dependency Dashboard (and any issue) could not be created or closed. Resolve the concrete open/closed state names for the `Issue` work item type from its process via `getWorkItemTypeStates`, grouped by state category (Proposed/InProgress = open, Completed/Resolved/Removed = closed). Omit `System.State` on create so Azure DevOps applies the work item type's default initial state. Classify issues open/closed by state category rather than the literal `Closed`. Fall back to the previous `New`/`Closed` names when the states cannot be read (e.g. older ADO Server). Result is cached per repository. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * fix(platform/azure): prefer Completed state as close target Address review: closedNames[0] picked the first state across the Completed/Resolved/Removed categories in workflow order, so processes that order a Resolved-category state before the Completed one (e.g. a custom inherited Agile process) would close work items to `Resolved` instead of `Closed`, changing prior behavior. Resolve the close target from the `Completed` category first, falling back to the wider closed set only when no Completed state exists. The full closed set is still used to classify already-closed items. Add tests covering a process where `Resolved` is ordered before `Closed`. * fix(platform/azure): address review feedback on state resolution - Extract namesByCategory into a module-level function declaration instead of an arrow function assigned to a variable. - Add a test where the Issue type exposes a closed-category state but no Completed state, exercising the completedNames[0] ?? closedNames[0] fallback (restores 100% patch coverage). - Reword the readme to avoid possessives per the style guide. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * refactor(platform/azure): simplify state resolution per review - use stateColors.find for the Completed close target instead of an extra namesByCategory pass over a single-element array - document that the open-state fallback may pick a closed state when a process exposes only closed states (intentional, not a bug) - reuse the workItemType const instead of repeating the 'Issue' literal Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * fix(platform/azure): resolve work item states via Lazy getWorkItemStates was async with a plain null-check cache guard, so two concurrent callers could both pass the guard and each fire a duplicate getWorkItemTypeStates request. Wrap resolution in `Lazy<Promise<...>>` so the executor runs once and all callers share the same promise. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>