Release: publish script, and remove broken trimming from the release workflow #6

Merged
hannah-vernon merged 2 commits from dev into main 2026-08-21 14:12:19 -05:00

Summary

Promotes dev to main. Adds publish.ps1 and disarms a release workflow that would publish non-functional artifacts.

Why this one matters

main currently carries -p:PublishTrimmed=true on both publish steps in .forgejo/workflows/release.yml. Trimming disables reflection-based serialization, and SiteConfig and SiteState are both bound with System.Text.Json reflection. A trimmed build compiles with six IL2026 warnings and then throws before reading the first config file:

Unhandled exception. System.InvalidOperationException: Reflection-based serialization
has been disabled for this application. Either use the source generator APIs or
explicitly configure the 'JsonSerializerOptions.TypeInfoResolver' property.
   at System.Text.Json.JsonSerializer.Deserialize[TValue](String, JsonSerializerOptions)
   at VigilanceSentinel.Program.RunAsync(String, ConsoleWriter) in Program.cs:line 135

Tagging any v* release from main as it stands would publish a linux-x64 and a win-x64 artifact that cannot start. No tags exist in this repository, so nothing broken has ever shipped, and the currently deployed binary was published manually rather than through the workflow, so it is unaffected.

This PR removes trimming from both steps.

Contents

publish.ps1 | new, wraps the dotnet publish invocation
.forgejo/workflows/release.yml | remove PublishTrimmed from both publish steps
README.md | document the script; warn against re-adding trimming
ARCHITECTURE.md | Building section with the same warning

219 insertions, 3 deletions.

publish.ps1

.\publish.ps1                          # tests, then current OS
.\publish.ps1 -Runtime all -Clean      # every supported runtime, fresh output
.\publish.ps1 -Runtime linux-x64 -SkipTests

Writes self-contained single-file binaries to publish/<runtime>/, which is already gitignored. Tests run first so a failing build produces no artifact.

It deliberately offers no trimming switch, because a switch that produces a non-functional binary is a trap. Re-enabling trimming would require a JsonSerializerContext source generator for SiteConfig and SiteState; that requirement is recorded in the script header, README.md, and ARCHITECTURE.md.

Verification

  • publish.ps1 parse-validated with [Parser]::ParseFile, 0 errors, CRLF throughout, comment-based help present.
  • Untrimmed output run against a real site config: all five checks reported, exit code 0.
  • Trimmed output run against the same config: crashed on startup, as quoted above.
  • dotnet test: 22 passed, 0 failed.
  • Sizes for the record: 14.1 MB trimmed and broken, 64.4 MB untrimmed and working.

Notes

  • main is already an ancestor of dev, so this should not be flagged out-of-date. PR #5's branch carried the reconciliation.
  • <Version> stays at 1.1.0. No application code changed in this PR, only build tooling and the workflow, so a rebuild reports the same version with a different commit hash. Say if you would prefer 1.1.1 so the deployed build is distinguishable.

Assumptions

  • Removing trimming is preferred over adding a source generator now. The generator is the better long-term fix if binary size matters; 64 MB is large for a monitoring utility, and that tradeoff is worth revisiting separately.
  • No redeployment is required from this PR. The running binary is untrimmed and already includes the daily_post check.

Deployment

None required. This changes build tooling and CI only; no application behaviour is altered.

## Summary Promotes `dev` to `main`. Adds `publish.ps1` and disarms a release workflow that would publish non-functional artifacts. ## Why this one matters `main` currently carries `-p:PublishTrimmed=true` on both publish steps in `.forgejo/workflows/release.yml`. Trimming disables reflection-based serialization, and `SiteConfig` and `SiteState` are both bound with `System.Text.Json` reflection. A trimmed build compiles with six IL2026 warnings and then throws before reading the first config file: ``` Unhandled exception. System.InvalidOperationException: Reflection-based serialization has been disabled for this application. Either use the source generator APIs or explicitly configure the 'JsonSerializerOptions.TypeInfoResolver' property. at System.Text.Json.JsonSerializer.Deserialize[TValue](String, JsonSerializerOptions) at VigilanceSentinel.Program.RunAsync(String, ConsoleWriter) in Program.cs:line 135 ``` Tagging any `v*` release from `main` as it stands would publish a linux-x64 and a win-x64 artifact that cannot start. No tags exist in this repository, so nothing broken has ever shipped, and the currently deployed binary was published manually rather than through the workflow, so it is unaffected. This PR removes trimming from both steps. ## Contents `publish.ps1` | new, wraps the `dotnet publish` invocation `.forgejo/workflows/release.yml` | remove `PublishTrimmed` from both publish steps `README.md` | document the script; warn against re-adding trimming `ARCHITECTURE.md` | Building section with the same warning 219 insertions, 3 deletions. ## publish.ps1 ```powershell .\publish.ps1 # tests, then current OS .\publish.ps1 -Runtime all -Clean # every supported runtime, fresh output .\publish.ps1 -Runtime linux-x64 -SkipTests ``` Writes self-contained single-file binaries to `publish/<runtime>/`, which is already gitignored. Tests run first so a failing build produces no artifact. It deliberately offers no trimming switch, because a switch that produces a non-functional binary is a trap. Re-enabling trimming would require a `JsonSerializerContext` source generator for `SiteConfig` and `SiteState`; that requirement is recorded in the script header, `README.md`, and `ARCHITECTURE.md`. ## Verification - `publish.ps1` parse-validated with `[Parser]::ParseFile`, 0 errors, CRLF throughout, comment-based help present. - Untrimmed output run against a real site config: all five checks reported, exit code 0. - Trimmed output run against the same config: crashed on startup, as quoted above. - `dotnet test`: 22 passed, 0 failed. - Sizes for the record: 14.1 MB trimmed and broken, 64.4 MB untrimmed and working. ## Notes - `main` is already an ancestor of `dev`, so this should not be flagged out-of-date. PR #5's branch carried the reconciliation. - `<Version>` stays at `1.1.0`. No application code changed in this PR, only build tooling and the workflow, so a rebuild reports the same version with a different commit hash. Say if you would prefer 1.1.1 so the deployed build is distinguishable. ## Assumptions - Removing trimming is preferred over adding a source generator now. The generator is the better long-term fix if binary size matters; 64 MB is large for a monitoring utility, and that tradeoff is worth revisiting separately. - No redeployment is required from this PR. The running binary is untrimmed and already includes the `daily_post` check. ## Deployment None required. This changes build tooling and CI only; no application behaviour is altered.
Add publish.ps1, and stop trimming release artifacts
All checks were successful
Build and Test / build (pull_request) Successful in 59s
15cdae4eb9
publish.ps1 wraps the dotnet publish invocation so a developer does not have to remember the flag combination.  It runs the tests first so a failing build produces no artifact, writes self-contained single-file binaries to publish/ (already gitignored), and supports -Runtime all for cross-platform builds.

Building the trimmed variant to check whether the release workflow was safe showed that it is not.  PublishTrimmed disables reflection-based serialization, and both SiteConfig and SiteState are bound with System.Text.Json reflection.  The build emits six IL2026 warnings and the resulting binary throws before reading the first config file:

    System.InvalidOperationException: Reflection-based serialization has been
    disabled for this application.

release.yml carried -p:PublishTrimmed=true on both the linux-x64 and win-x64 steps, so tagging any v* release would have published two artifacts that cannot start.  No tags exist yet, so nothing broken was ever shipped.  Removed from both steps.

publish.ps1 deliberately offers no trimming switch, because a switch that produces a non-functional binary is a trap.  Re-enabling it would require a JsonSerializerContext source generator for those two models; that requirement is recorded in the script header, README.md, and ARCHITECTURE.md so it is not naively re-added.

Verified: untrimmed publish output runs all five checks against the live site and exits 0.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Merge pull request 'Add publish.ps1, and stop trimming release artifacts' (#5) from feature/publish-script into dev
All checks were successful
Build and Test / build (push) Successful in 58s
Build and Test / build (pull_request) Successful in 58s
f8cb5582c7
Reviewed-on: #5
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
hannah-vernon/vigilance-sentinel!6
No description provided.