You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
v0.8.2: trim psd1 ReleaseNotes - collapse 0.7.88..0.7.98 stubs into 0.7.72-0.7.98 cumulative + add v0.8.2 follow-up bullets
PSGallery surfaces PrivateData.PSData.ReleaseNotes on the module page,
but the limit is 10000 characters. The previous v0.8.2 follow-up commit
(2f8953b) extended the user-visible v0.8.2 entry with NoWindowTag
enrichment and Step.3 Allow-list trim bullets, which pushed the block
to 11047 chars - 1047 over the PSGallery cap. Publish would fail.
Two changes here:
1. Refreshed the v0.8.2 block in psd1 ReleaseNotes to match the
CHANGELOG / README / release-history additions:
- -View Audit NoWindowTag row enrichment (named clusters grouped by
UpdateRing, sort rank 7 -> 10, optional-tag clarification).
- Step.3 GH/ADO Allow-list section trimmed (one-liner + dedicated
'How to fix - edit $schedulePath' subsection).
2. Collapsed the cumulative section: was 'Versions 0.7.72 - 0.7.86'
plus 11 individual 0.7.87..0.7.98 'see CHANGELOG' stubs. Now a
single 'Versions 0.7.72 - 0.7.98 (cumulative)' paragraph. Per-version
detail is still one click away in the CHANGELOG link.
New length: 7731 / 10000 (was 11047). Both Pester guards still pass:
- 'psd1 ReleaseNotes first ## Version heading matches manifest
ModuleVersion' (first heading is still v0.8.2)
- 'Should have ReleaseNotes within the PSGallery character limit'
(7731 < 10000)
Test-ModuleManifest parses clean. No code changes; psd1-only.
Copy file name to clipboardExpand all lines: AzLocal.UpdateManagement/AzLocal.UpdateManagement.psd1
+7-102Lines changed: 7 additions & 102 deletions
Original file line number
Diff line number
Diff line change
@@ -221,17 +221,19 @@
221
221
222
222
# ReleaseNotes of this module
223
223
ReleaseNotes=@'
224
-
## Version 0.8.2 - Test-AzLocalApplyUpdatesScheduleCoverage -View Recommend snippet now embeds a `# All cron times below are UTC` comment + emits an `Indent tip` blockquote warning operators about IDE auto-indent-on-paste; five new internal pipeline-host helpers (Get/Set/Add/Write-AzLocalPipeline*) laid down as foundations for the upcoming executable-YAML refactor
224
+
## Version 0.8.2 - Test-AzLocalApplyUpdatesScheduleCoverage operator-UX release: -View Recommend snippet embeds `# All cron times below are UTC` comment + `Indent tip` blockquote; -View Audit `NoWindowTag` row now names affected clusters grouped by `UpdateRing` + sorts AFTER Covered; Step.3 GH/ADO Allow-list section trimmed; five new internal pipeline-host helpers (Get/Set/Add/Write-AzLocalPipeline*) laid down as foundations for the upcoming executable-YAML refactor
225
225
226
226
Operator-experience release. No public API changes; no output-shape changes that break existing scripts.
227
227
228
-
- **`Test-AzLocalApplyUpdatesScheduleCoverage -View Recommend` paste-time pain points fixed** in the advisor's emitted snippet:
228
+
- **`Test-AzLocalApplyUpdatesScheduleCoverage -View Recommend` paste-time pain points fixed** in the advisor''s emitted snippet:
229
229
1. The snippet now embeds a `# All cron times below are UTC ...` comment directly above `schedule:` (GitHub) and `schedules:` (Azure DevOps). Both platforms evaluate `cron:` in UTC regardless of repo / runner / agent timezone, but operators repeatedly burned time converting from a local-time mental model. The comment makes the snippet self-documenting once pasted into `Step.6_apply-updates.yml`.
230
230
2. The advisor now emits a `> **Indent tip.**` blockquote directly above the snippet. The GH snippet is intentionally at 2-space indent (so `schedule:` is a sibling of the existing `workflow_dispatch:` under `on:`); pasting with the cursor sitting inside the `# BEGIN-AZLOCAL-CUSTOMIZE:schedule-triggers` comment block causes VS Code (and JetBrains IDEs) to silently double the indent, producing the YAML error *"All mapping items must start at the same column"*. The blockquote explains the cause and how to recover.
231
+
- **`Test-AzLocalApplyUpdatesScheduleCoverage -View Audit` `NoWindowTag` row is now actionable on its own**: the recommendation lists the first 15 affected cluster names grouped by their `UpdateRing` tag (or `(none)` when both tags are missing), e.g. `Prod -> hci-syd-01, hci-syd-02; Wave1 -> hci-mel-01 (+3 more) (showing first 15 of 42)`. The issue text is clarified to say the `UpdateStartWindow` tag is optional (the runtime gate only enforces a window when the tag is set, so untagged clusters are not a blocker), and the row sorts AFTER `Covered` (rank 10 instead of 7) so these informational rows do not push real coverage gaps off-screen.
232
+
- **Step.3 Allow-list section trimmed in both GH and ADO scaffolds**: the `Allow-list coverage (schema v2)` subsection no longer emits the verbose `> Tip - per-ring overrides` paragraph + 3-row example block. Inheriting the top-level allow-list IS the expected steady state for most fleets; the verbose tip was misleading operators into thinking they had to add overrides. The new shape is a one-line steady-state confirmation plus a dedicated `### How to fix - edit $schedulePath` subsection (naming the schedule file) and a single-row YAML example for the case where an operator wants to PIN a ring to a specific update (e.g. keep Prod on YY04/YY10 feature drops only).
231
233
- **Five new internal pipeline-host helpers added** (not exported, no user-visible effect in v0.8.2): `Get-AzLocalPipelineHost`, `Set-AzLocalPipelineOutput`, `Add-AzLocalPipelineStepSummary`, `Write-AzLocalPipelineNotice`, `Write-AzLocalPipelineWarning`. They abstract over GitHub Actions vs Azure DevOps output channels (`$env:GITHUB_OUTPUT` vs `##vso[task.setvariable]`, etc.). 23 new Pester assertions cover the three host modes (GitHub via `$env:GITHUB_ACTIONS`, AzureDevOps via `$env:TF_BUILD`, Local fallback).
232
234
- **GENERATED_AGAINST_MODULE_VERSION** pin moves from ''0.8.1'' to ''0.8.2'' across all 20 bundled `Step.{0..9}.yml` templates.
233
235
234
-
Apply via `Install-Module AzLocal.UpdateManagement -Force` (or `Update-Module`). Re-run `Test-AzLocalApplyUpdatesScheduleCoverage -View Recommend` once to pick up the new self-documenting snippet (cron values unchanged from v0.8.1).
236
+
Apply via `Install-Module AzLocal.UpdateManagement -Force` (or `Update-Module`). Re-run `Test-AzLocalApplyUpdatesScheduleCoverage` once to pick up (a) the new self-documenting `-View Recommend` snippet (cron values unchanged from v0.8.1), and (b) the enriched `-View Audit` `NoWindowTag` recommendation.
235
237
236
238
## Version 0.8.1 - Test-AzLocalApplyUpdatesScheduleCoverage -View Recommend GH snippet emits ONLY the `schedule:` block (no `on:` / `workflow_dispatch:` lines) so it can be pasted straight into Step.6_apply-updates.yml without producing a duplicate-key YAML error
Apply via `Install-Module AzLocal.UpdateManagement -Force` (or `Update-Module`). Run `Update-AzLocalPipelineExample -Destination <path>` to refresh the two affected `Step.7_monitor-updates.yml` files. The fix sits outside any `BEGIN-AZLOCAL-CUSTOMIZE` block, so operator customisations elsewhere in those pipelines are preserved.
277
-
278
-
## Version 0.7.93 - Pipeline JUnit summaries: fix NaNms in duration column (+ Pester regression guard)
0 commit comments