fix(release): keep build and publish on one resource configuration; smoke test what ships #88

2026-10-10T17:48:57Z

KofTwentyTwo commented

2026-10-10 17:48:57 +00:00

(Migrated from github.com)

What

v1.0.1 and the beta.3 rehearsal crash at startup (0xc000027b in Microsoft.UI.Xaml.dll). Root cause in #87: the shared release workflow builds Release (framework-dependent) and then publishes self-contained into the same obj, and the incremental _GenerateProjectPriFileCore target skipped because its new inputs (the Windows App SDK .pri files from the NuGet cache) were older than the index it had already written. The published gclo.pri was 115 KB instead of 2.3 MB and lacked the WinUI theme resources.

gclo/gclo.csproj: WindowsPackageType=None and WindowsAppSDKSelfContained=true unconditionally. gclo ships only unpackaged and self-contained, so build and publish now share one resource configuration and the incremental index is always right.
release.yml: new smoke job between the gates and the shared release. It restores, builds Release and publishes with the shared workflow's exact commands (same incremental obj state), then runs the FlaUI suite against the published gclo.exe through GCLO_UITEST_EXE. release needs it, so a build that does not start can never be published again.
docs/RELEASING.md: the smoke job in "Watch the workflow".

Closes #87 (part of #62). Shared-workflow follow-up filed as KofTwentyTwo/standards#22.

Done outside this PR

v1.0.1 marked prerelease with a warning in its notes ("A broken release" runbook), so stable installs stop receiving it.
1.0.0 reinstalled on the maintainer's machine.

How it was tested

From clean bin/obj with the workflow's exact sequence (locked restore, dotnet build gclo.slnx -c Release -p:Platform=x64, the publish command): before the csproj change gclo.pri = 115,816 bytes and the app exits 0xC000027B; after it the build and the publish both give 2,298,032 bytes and the published app opens its main window.
actionlint clean.
Next: tag v1.0.2-beta.1, install it on a clean machine, then v1.0.2.

🤖 Generated with Claude Code

## What v1.0.1 and the beta.3 rehearsal crash at startup (`0xc000027b` in `Microsoft.UI.Xaml.dll`). Root cause in #87: the shared release workflow builds Release (framework-dependent) and then publishes self-contained into the same `obj`, and the incremental `_GenerateProjectPriFileCore` target skipped because its new inputs (the Windows App SDK `.pri` files from the NuGet cache) were older than the index it had already written. The published `gclo.pri` was 115 KB instead of 2.3 MB and lacked the WinUI theme resources. - `gclo/gclo.csproj`: `WindowsPackageType=None` and `WindowsAppSDKSelfContained=true` unconditionally. gclo ships only unpackaged and self-contained, so build and publish now share one resource configuration and the incremental index is always right. - `release.yml`: new `smoke` job between the gates and the shared release. It restores, builds Release and publishes with the shared workflow's exact commands (same incremental `obj` state), then runs the FlaUI suite against the published `gclo.exe` through `GCLO_UITEST_EXE`. `release` needs it, so a build that does not start can never be published again. - `docs/RELEASING.md`: the smoke job in "Watch the workflow". Closes #87 (part of #62). Shared-workflow follow-up filed as KofTwentyTwo/standards#22. ## Done outside this PR - v1.0.1 marked prerelease with a warning in its notes ("A broken release" runbook), so stable installs stop receiving it. - 1.0.0 reinstalled on the maintainer's machine. ## How it was tested - From clean `bin`/`obj` with the workflow's exact sequence (locked restore, `dotnet build gclo.slnx -c Release -p:Platform=x64`, the publish command): before the csproj change `gclo.pri` = 115,816 bytes and the app exits `0xC000027B`; after it the build and the publish both give 2,298,032 bytes and the published app opens its main window. - `actionlint` clean. - Next: tag `v1.0.2-beta.1`, **install it on a clean machine**, then `v1.0.2`. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

github-advanced-security[bot] (Migrated from github.com) reviewed

2026-10-10 17:49:19 +00:00

.github/workflows/release.yml

						
				@@ -90,0 +109,4 @@

				      # No NuGet cache: a release workflow must not consume runtime-generated

				      # caches (zizmor cache-poisoning); the locked restore is deterministic.

				      - name: Set up .NET SDK

				        uses: actions/setup-dotnet@a98b56852c35b8e3190ac28c8c2271da59106c68 # v6.0.0

github-advanced-security[bot] (Migrated from github.com) commented

2026-10-10 17:49:18 +00:00

zizmor /

runtime artifacts potentially vulnerable to a cache poisoning attack: this step

Show more details

## zizmor / runtime artifacts potentially vulnerable to a cache poisoning attack: this step [Show more details](https://github.com/KofTwentyTwo/gclo/security/code-scanning/7)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: KofTwentyTwo/gclo#88