AzLocal.UpdateManagement v0.8.78: pipeline-summary UX polish (JUnit reclassification, Up-to-Date surfacing, download-artifact@v7)

[NeilBird]

Summary

AzLocal.UpdateManagement v0.8.78 - patch release. Pipeline-summary UX polish driven by operator feedback on Step.07 (apply-updates). Three independent improvements, all backward-compatible.

Changes

1. JUnit reclassification: gate-respect != failure

Export-ResultsToJUnitXml now renders ScheduleBlocked, SideloadedBlocked, and ExcludedByTag outcomes as <skipped> instead of <failure>. These are by-design opt-in gates honoured by Start-AzLocalClusterUpdate; treating them as failures was misleading and caused dorny/test-reporter to flip Step.07 RED on otherwise-successful runs that exercised the schedule-aware / sideload-gated / tag-excluded paths. HealthCheckBlocked deliberately stays a <failure> because a critical health failure IS an actionable operational issue.

2. Apply Updates summary shows the FULL ring picture

New optional -UpToDateCount / -NotReadyCount parameters on Add-AzLocalApplyUpdatesStepSummary add Already Up to Date and Not Ready (needs attention before updating) rows to the Readiness KPI table. Both apply-updates YAMLs (GitHub Actions + Azure DevOps) wire the upstream readiness.UpToDateCount / readiness.NotReadyCount outputs (emitted since v0.8.74) through to the summary task, so operators now see the full ring breakdown - eligible, started, skipped, blocked, up-to-date, needs-attention - all in one place.

3. actions/download-artifact@v6 -> @v7

Silences the persistent Node.js 20 deprecation warning on every Step.07 run; v7 ships native Node 24. v7 chosen over v8 because v8 has a breaking digest-mismatch=error default that would block legitimate cross-job artifact reuse.

Readiness-gate verification

Operator question: "do we surface Ready clusters that have a previously-failed in-progress run?" Answer: no. Get-AzLocalClusterUpdateReadiness and Start-AzLocalClusterUpdate (Step 3) both predicate Ready on updateSummary.properties.state -in @('UpdateAvailable','Ready','ReadyToInstall'). NeedsAttention / UpdateInProgress / UpdateFailed / PreparationFailed clusters all correctly land in the Not-Ready bucket. No code change required.

Tests

• Repurposed: 'JUnit XML export handles ScheduleBlocked' and SideloadedBlocked Contexts now assert <skipped> (not <failure>) and matching summary attrs (failures=0, skipped=1).
• New: 'Export-ResultsToJUnitXml renders ExcludedByTag as <skipped> (v0.8.78)'.
• New: 'Has v0.8.78 optional readiness-breakdown parameters UpToDateCount/NotReadyCount' on Add-AzLocalApplyUpdatesStepSummary.
• Module-version assertion bumped to 0.8.78.

Full suite locally: 1150 passed, 0 failed, 39 skipped, 1189 total. Exit 0.

Bundled pipelines

All 22 bundled pipeline templates bump GENERATED_AGAINST_MODULE_VERSION from '0.8.77' to '0.8.78'. Only the GitHub Actions and Azure DevOps apply-updates.yml YAMLs have body changes (UpToDateCount/NotReadyCount wiring + GHA download-artifact bump); the other 20 templates are version-marker-only.

Public API surface

No change. Still 60 exported functions. Two new params on Add-AzLocalApplyUpdatesStepSummary are both [object] = -1 (parser tolerates empty pipeline-macro strings), so callers omitting them see identical behaviour to v0.8.77.