fix(release): retire obsolete 1.6.38 publishers and block SBOM overwrite - #377
Conversation
…lden-installer.yml
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2663dc8ba0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| .\scripts\publish-windows-portable.ps1 -Version 1.6.40 | ||
| .\scripts\build-windows-installer.ps1 -Version 1.6.37 -Runtime win-x64 |
There was a problem hiding this comment.
Align the installer example with the current release version
When a user follows these adjacent local-packaging commands, the first publishes version 1.6.40 while build-windows-installer.ps1 derives its default input directory from version 1.6.37. The installer command therefore looks for dist/ARSAS-1.6.37-win-x64 instead of the newly published output, either failing with “Published application folder was not found” or packaging stale 1.6.37 files if that directory remains. Update the installer example to use the same current version.
Useful? React with 👍 / 👎.
Root cause
Three one-off v1.6.38 workflow entrypoints remain runnable on current main; two can replace historical release assets and use
--latest, bypassing the stable asset immutability guarantees introduced in #373. The manual supply-chain backfill can also overwrite an existing stable SBOM using--clobber.Scope
Non-regression boundary
No application runtime, Smart Discovery, SCL, DataSet, reporting, engine lock, version/tag, historical release, or website asset is changed. CI and the post-merge production authority must pass before merge.