Skip to content

One-off: restamp workflow for the v3.4.0 archives (#2113/#2147/#2151) - #2152

Closed
erikdarlingdata wants to merge 1 commit into
mainfrom
restamp-workflow
Closed

erikdarlingdata wants to merge 1 commit into
mainfrom
restamp-workflow

Conversation

@erikdarlingdata

Copy link
Copy Markdown
Owner

Erik-authorized (this morning, on the back of #2151 — the third user report from the 3.4.0 stamp): adds a workflow_dispatch-only workflow that rebuilds the three PLAIN archives from restamp-3.4.0 (= the v3.4.0 tag + only the single-source stamp fix cherry-picked, verified version-properties-only) and clobbers them + merged checksums onto the existing v3.4.0 release.

  • Stamp-verification gate before any upload: the job throws if the published binaries don't read 3.4.0.
  • Checksums merged, not replaced: rebuilt assets get new hashes; untouched assets keep their existing lines.
  • Velopack chain untouched by design (delta/full nupkgs, Setup.exe, releases.*.json) — regenerating the updater feed blind risks breaking updates; that stays the release-cutter's call.
  • Targets main only because workflow_dispatch requires default-branch registration. Revert after the run.

Build steps mirror nightly.yml verbatim (same publish shapes, archive layouts, pg-runtime staging), version fixed at plain 3.4.0.

Erik-authorized: rebuilds the three plain archives from restamp-3.4.0
(= v3.4.0 tag + only the stamp fix) with a stamp-verification gate, merges
checksums, and clobbers onto the existing release. Velopack chain untouched
by design. Revert this commit after the run.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@erikdarlingdata

Copy link
Copy Markdown
Owner Author

Closing — the branch gate correctly only allows dev→main, and there's a cleaner path: push-triggered workflows run from any branch without default-branch registration. The workflow now lives on restamp-3.4.0 with an on:push trigger scoped to that branch.

@erikdarlingdata
erikdarlingdata deleted the restamp-workflow branch August 10, 2026 06:42
Comment on lines +44 to +86
- name: Publish Lite
run: dotnet publish Lite/PerformanceMonitorLite.csproj -c Release -o publish/Lite

- name: Publish Darling Service
run: dotnet publish Darling/PerformanceMonitor.Darling.Service/PerformanceMonitor.Darling.Service.csproj -c Release -o publish/DarlingService

- name: Publish Darling Viewer
run: dotnet publish Darling/PerformanceMonitor.Darling.Viewer/PerformanceMonitor.Darling.Viewer.csproj -c Release -o publish/DarlingViewer

- name: Verify the stamp actually derives (the whole point)
shell: pwsh
run: |
$v = (Get-Item publish/Lite/PerformanceMonitorLite.dll).VersionInfo
Write-Host "Lite FileVersion=$($v.FileVersion) ProductVersion=$($v.ProductVersion)"
if ($v.FileVersion -notlike '3.4.0*') { throw "Lite still stamped $($v.FileVersion) — abort before touching the release" }
$d = (Get-Item publish/DarlingService/PerformanceMonitor.Darling.Service.dll).VersionInfo
Write-Host "Darling FileVersion=$($d.FileVersion)"
if ($d.FileVersion -notlike '3.4.0*') { throw "Darling still stamped $($d.FileVersion) — abort" }

- name: Cache Darling pg-runtime.zip
id: cache-pg-runtime
uses: actions/cache@v6
with:
path: Darling/artifacts/pg-runtime.zip
key: pg-runtime-${{ runner.os }}-${{ hashFiles('Darling/tools/fetch-pg-runtime.ps1') }}

- name: Build Darling pg-runtime.zip
if: steps.cache-pg-runtime.outputs.cache-hit != 'true'
shell: pwsh
run: ./Darling/tools/fetch-pg-runtime.ps1

- name: Package archives (plain 3.4.0 names)
shell: pwsh
run: |
New-Item -ItemType Directory -Force -Path releases
Compress-Archive -Path 'publish/Lite/*' -DestinationPath "releases/PerformanceMonitorLite-3.4.0.zip" -Force

$darlingDir = 'publish/Darling'
New-Item -ItemType Directory -Force -Path "$darlingDir/viewer" | Out-Null
Copy-Item 'publish/DarlingService/*' $darlingDir -Recurse
Copy-Item 'publish/DarlingViewer/*' "$darlingDir/viewer" -Recurse
Copy-Item 'Darling/artifacts/pg-runtime.zip' $darlingDir
Compress-Archive -Path 'publish/Darling/*' -DestinationPath "releases/PerformanceMonitorDarling-3.4.0.zip" -Force

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No SignPath signing before these archives are built and clobbered onto the release.

build.yml's real release path (if: github.event_name == 'release') publishes Lite/Darling, then routes them through signpath/github-action-submit-signing-request (Sign Lite / Sign Darling, ~lines 360-411) and zips the signed output (signed/Lite/*, signed/Darling/*). This workflow publishes straight to publish/Lite / publish/DarlingService / publish/DarlingViewer and zips those directly — no signing step at all.

Since the comment block at the top says this mirrors nightly.yml "verbatim," that's consistent with nightly (which is also never signed), but nightly builds aren't uploaded as the plain-zip assets on a real numbered release. Running this as-is will clobber the currently-signed PerformanceMonitorLite-3.4.0.zip and PerformanceMonitorDarling-3.4.0.zip on the v3.4.0 release with unsigned executables — a real regression in binary trust/provenance for anyone who (re)downloads after this runs (likely triggering SmartScreen/AV warnings that the original signed release didn't have).

Worth confirming this is an intentional, accepted trade-off before running — the PR description doesn't mention it.

Comment on lines +53 to +61
- name: Verify the stamp actually derives (the whole point)
shell: pwsh
run: |
$v = (Get-Item publish/Lite/PerformanceMonitorLite.dll).VersionInfo
Write-Host "Lite FileVersion=$($v.FileVersion) ProductVersion=$($v.ProductVersion)"
if ($v.FileVersion -notlike '3.4.0*') { throw "Lite still stamped $($v.FileVersion) — abort before touching the release" }
$d = (Get-Item publish/DarlingService/PerformanceMonitor.Darling.Service.dll).VersionInfo
Write-Host "Darling FileVersion=$($d.FileVersion)"
if ($d.FileVersion -notlike '3.4.0*') { throw "Darling still stamped $($d.FileVersion) — abort" }

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor: this stamp-verification gate checks publish/Lite/PerformanceMonitorLite.dll and publish/DarlingService/PerformanceMonitor.Darling.Service.dll, but not publish/DarlingViewer/PerformanceMonitor.Darling.Viewer.dll, even though the viewer ships inside PerformanceMonitorDarling-3.4.0.zip (viewer/ subfolder, packaged a few steps down). If the single-source stamp fix somehow didn't reach the Viewer project, this gate wouldn't catch it before the archive gets uploaded. Presumably low-risk since it's one shared version source, but the gate's stated purpose is "verify the stamp actually derives" for everything about to ship.

@claude

claude Bot commented Aug 10, 2026

Copy link
Copy Markdown

Review

This PR adds a single one-off, workflow_dispatch-only GitHub Actions workflow (.github/workflows/restamp.yml) — no T-SQL or Lite/Darling app code involved, so the usual T-SQL style guide and Lite/Darling code-parity concerns don't apply here. It builds Windows and Linux artifacts symmetrically for both editions, so there's no drift between them within this file.

Main finding (left inline, on the packaging step): the workflow skips SignPath signing entirely. build.yml's real release path signs Lite and Darling before zipping (Sign Lite / Sign Darling steps → zips signed/Lite/* and signed/Darling/*); this workflow zips straight from the raw dotnet publish output. It says it mirrors nightly.yml "verbatim," which is true — but nightly builds are never signed and never uploaded as a real release's plain-zip assets. Run as-is, this will clobber the currently-signed PerformanceMonitorLite-3.4.0.zip / PerformanceMonitorDarling-3.4.0.zip on the v3.4.0 release with unsigned executables, which is a real trust/provenance regression for anyone downloading after the run (potential SmartScreen/AV friction that the original release didn't have). Worth an explicit call before this runs, since the PR description doesn't mention it.

Minor (left inline): the stamp-verification gate checks Lite and Darling Service DLLs but not the Darling Viewer DLL, even though the Viewer ships inside the Darling zip. Probably fine given the single-source version stamp, but worth a second look.

Checked and looks correct:

  • Checksum handling (separate SHA256SUMS.txt for Windows-built assets vs. SHA256SUMS-linux.txt for the Linux tar.gz, merge-not-replace logic for untouched lines) matches the split convention used in both nightly.yml and build.yml.
  • Archive layout (Lite zip, Darling zip with service at root + viewer/ subfolder + pg-runtime.zip beside the service exe) matches the production layout.
  • needs: windows ordering on the linux job avoids a race with the checksum merge/upload.
  • Scope is clearly documented (plain archives only, Velopack chain untouched) and the file is explicitly marked for deletion after the one-off run.
  • No secrets handling or injection issues — GH_TOKEN usage is standard, and the checksum-merge string matching uses fixed literal filenames.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant