AzLocal.UpdateManagement v0.8.74 - consistent 'Up to Date' classification, No-Clusters-Ready breakdown, deep-tree Progress column, step-summary hyperlink tidy-up

[NeilBird]

Summary

v0.8.74 makes the "Up to Date" cluster classification consistent across the Step.5 readiness report, the Step.7 readiness gate, and the Step.9 fleet update-status report; corrects the long-standing Progress column under-reporting in the Step.7 in-flight monitor and the standalone HTML "Recent Update Run History" report; and drops the dead target="_blank" portal-link attributes that the GitHub Actions / Azure DevOps step-summary sanitisers were stripping anyway (replaced with an explicit Ctrl/Cmd/middle-click tip above each affected table).

No public API or export-count change (still 60 exports).

What changed

Consistent "Up to Date" classification

• Fixed: fully-patched clusters were mis-classified as "not ready". Step.5 (Export-AzLocalClusterUpdateReadinessReport) showed 0 in its "Up to date" count and listed such clusters in the "Not-Ready clusters (review first)" table; Step.7 (Export-AzLocalClusterReadinessGateReport) rendered them with a no-entry icon in the binary Ready? column - both implying failure. Root cause: the "Up to Date" test required AllAvailableUpdates to be empty, but a cluster that has installed all updates still lists those (now-Installed) package names there.
• Added Get-AzLocalClusterReadinessStatus private helper - the single source of truth for the readiness priority cascade (UpdateFailed > ActionRequired > HealthFailure > SbeBlocked > InProgress > ReadyForUpdate > UpToDate > NeedsInvestigation). Step.5, Step.7 and Step.9 all classify through this one helper now.
• Changed: Step.7's per-cluster table replaces the binary Ready? column with a readable Status column and emits a new additive UP_TO_DATE_COUNT / UpToDateCount step output (-PassThru returns UpToDateCount). Step.5's "All clusters detail" table gets the same readable Status label and excludes Up-to-Date / Ready clusters from its "Not-Ready" table.

No-Clusters-Ready breakdown

• Add-AzLocalNoReadyClustersStepSummary now accepts -UpToDateCount / -NotReadyCount and renders an Up to Date vs Not Ready breakdown table, so already-patched clusters read as a healthy steady state rather than a fault. When every discovered cluster is up to date it logs an informational notice (not a warning) and points operators to the per-cluster Status / Blocking Reasons detail (the Check Update Readiness table + readiness-report.csv).
• Both the GitHub Actions and Azure DevOps apply-updates templates wire the two new counts through from the readiness gate job.

Deep-tree Progress column

• Fixed: the Progress column in the Step.7 in-flight monitor (Export-AzLocalUpdateRunMonitorReport, via Format-AzLocalUpdateRun) and the standalone HTML "Recent Update Run History" table (New-AzLocalFleetStatusHtmlReport, fed by Get-AzLocalFleetStatusData) had always been reporting the coarse top-level wrapper count (typically 1/2 steps) for the whole multi-hour run. Real Azure Local update runs only expose two top-level wrapper steps in properties.progress.steps - Prepare update (Success) and Start update (stays InProgress for the entire run) - so counting that level alone produced 1/2 steps (or 0/2 steps) regardless of real progress.
• Both reporting paths now walk the full nested step tree via a new private helper, Get-AzLocalUpdateRunStepStats, and report leaf-step completion as M/N steps (P%) (optionally suffixed with , K failed when leaf-level errors are present). Skipped leaves count as completed so a fully-finished run reaches 100%; wrapper steps are excluded so children aren't double-counted.
• Mirrors how CurrentStep already traverses the tree via Get-DeepestActiveStep.

Step-summary portal hyperlinks: stop pretending target="_blank" works

• The Cluster / Update portal hyperlinks rendered in Step.7 (Export-AzLocalUpdateRunMonitorReport in-flight + failed-runs tables), Step.8 (Export-AzLocalFleetUpdateStatusReport Update Run History table), and Step.10 (Export-AzLocalFleetHealthStatusReport Fleet Health Overview / By-Reason / Detailed Results tables) always opened in the current tab even though the markdown source emitted target="_blank" rel="noopener" on every anchor.
• Confirmed in the rendered HTML of a real GitHub Actions job summary: GitHub's GFM sanitiser strips the target attribute entirely and forces rel="nofollow". The Azure DevOps step-summary renderer applies an equivalent sanitisation. The behaviour is platform-imposed and not configurable - see Stack Overflow: open link in new tab with github markdown using target="_blank" (425-upvote accepted answer documents the same conclusion).
• All three emitters now render plain <a href="...">name</a> with no target / rel attributes (so the markdown source matches what actually reaches the rendered DOM, and the payload is slightly smaller), and each affected table is preceded by an explicit tip:

  Tip: Hold `Ctrl` (or `Cmd` on macOS) when clicking - or middle-click - Cluster or Update links to open them in a new tab. (GitHub markdown strips target="_blank".)

• The standalone HTML report (New-AzLocalFleetStatusHtmlReport) is unaffected - it is written as a raw .html artifact (not a step-summary), so its existing target="_blank" already works as intended in any browser. No change there.

Housekeeping

• GENERATED_AGAINST_MODULE_VERSION bumped 0.8.73 -> 0.8.74 across all bundled pipeline templates.
• CHANGELOG, README ("What's New in v0.8.74"), release-history, module manifest ReleaseNotes (kept under the 10,000-char PSGallery limit), and pipeline appendix doc updated.

Testing

Full Pester suite passes: 1133 passed, 0 failed, 1 skipped (pre-existing skip).

New / updated coverage:

• Get-AzLocalUpdateRunStepStats regression suite covers nested-tree traversal, Skipped-as-completed accounting, wrapper-step exclusion, the empty/$null cases, and the MaxDepth guard.
• Get-AzLocalFleetStatusData (HTML / CSV path) asserts the LatestRuns[].Progress field now reports leaf-step M/N steps (P%) for a 5-leaf in-flight fixture rather than the old 1/2 steps.
• Step.7 / Step.9 step-summary tests now assert plain <a href="...">name</a> markup (no target/rel), regress on target="_blank" ever reappearing, and require the Ctrl-click tip block above the cluster/update tables.