[mgradwohl]

Description

No CI step installed a new build over a real 0.8 install, or started one from a 0.8 config (#2488, #2489). This adds both to the release validate jobs, using #2720's clean quit (TASKSMACK_SCREENSHOT=<png>;after=5, #2933) to check what the app saves on exit.

The fixture is tests/App/fixtures/config-v0.8.0.toml (#2725), which v0.8.0 saved itself. The checks look for the settings changed in v0.8.0's UI when it was made, since each one differs from today's default: [theme] id = 'dracula', [font] size = 'large', [sampling] interval_ms = 2000 and history_max_seconds = 600, [ui] show_privilege_notice = false, and [process_columns] threads = true, user = false. A saved file must also have config_version, which v0.8.0 didn't write, so it shows the shutdown's save rewrote v0.8.0's file. Window size and position aren't checked, because an offscreen or runner display can change them.

Both smoke launches get a second run from v0.8.0's config:

• Linux (smoke-check.sh, for both the .deb and the .tar.gz): each binary runs twice, first from an empty TASKSMACK_CONFIG_DIR (unchanged), then from one holding a copy of the fixture. Both runs must exit 0, write the frame, save config.toml with its [theme] id, and log no [error]/[critical] line. The fresh run didn't check log lines before; the last dry run's Linux logs have only warnings, so this is safe. The second run must also have config_version and the fixture's settings. The asset log checks run on both.
• Windows ("Smoke-check extracted executable"): the launch moves into a loop over the two runs, each with its own config dir, frame and logs. Each run gets all the existing checks, and the seeded one also gets config_version and the fixture settings. The leave-no-trace scan now covers both runs, with both config dirs allowed, and the package folder is deleted once after both. The step timeout goes from 5 to 8 minutes for the second launch. One checkout now fetches the signature check and the fixture, so it's no longer limited to the signed leg.
• In the bare 24.04 container the fixture comes from actions/checkout. With no git there, the action falls back to downloading the tree through the REST API. Installing git would pull packages into the clean environment the .deb's Depends is checked in.

New validate-linux-upgrade job (x64):

• Fetch: TaskSmack-0.8.0-Linux.deb is fetched by name from the v0.8.0 release through the API, with the job's token. The release has no SHA256SUMS asset, so the file is checked against a pinned SHA-256 (the one tests/App/fixtures/README.md records) and against the release's own asset digest.
• v0.8.0 runs once: apt-get install puts v0.8.0 on. It then runs for 5 s from the fixture in $HOME/.config/tasksmack, where both versions look; v0.8.0 has no TASKSMACK_CONFIG_DIR. It must still be running when it's stopped. Its .deb doesn't declare the libc++/GL libraries its binary links, so the step installs those too.
• Upgrade: apt-get install of this run's .deb must exit 0. dpkg must report no trying to overwrite and no dpkg: error. The log must say Unpacking tasksmack (<new>) over (0.8.0), the installed version must be the new one, and dpkg --audit must be clean.
• Files after the upgrade: every file the new .deb ships must be installed byte-for-byte as shipped, docs and man pages aside (the ubuntu image's dpkg excludes them). The helper (/usr/libexec/tasksmack/tasksmack-helper) and the polkit policy are required by name, and their SHA-256s are printed. No v0.8.0 file the new .deb doesn't ship may be left. v0.8.0 had no helper or policy, so the upgrade installs them; on a later upgrade, the same check shows they were replaced.
• First start after the upgrade: the upgraded /usr/bin/TaskSmack starts with no TASKSMACK_CONFIG_DIR, so it finds v0.8.0's file by itself. It must quit cleanly, log no [error]/[critical] line, and save config_version with the fixture's settings kept.
• create-release now needs this job.

Change from the issue's plan: the issue puts the upgrade in validate-linux-package's bare ubuntu:24.04 container. That isn't possible: v0.8.0's .deb has Depends: libsdl3-0, and Ubuntu 24.04 has no SDL3 package. That's why the fixture was made on 26.04. So the upgrade runs in its own job, in an ubuntu:26.04 container, where libsdl3-0 installs and both versions run. It's x64 only, because v0.8.0 published no arm64 .deb.

Windows NSIS upgrade: out of scope. The .zip is portable, so there's nothing to upgrade. A comment in validate-windows-package points at #2302's installer.

CONTRIBUTING.md ("Release Artifact Validation") describes the second launch and the upgrade job.

Part of #2726 (the NSIS upgrade waits on #2302).

PR Size

Medium, over the size-S estimate: +540/−137, almost all in release.yml. The new upgrade job is about 230 lines. The Windows smoke step's diff is large mostly because its launch moved into a loop and was re-indented. CONTRIBUTING.md is 28 lines.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Build/CI improvement

Checklist

• I have read the CONTRIBUTING guidelines
• My code follows the project's coding standards
• I have run clang-tidy and addressed any warnings (no C++ changed)
• I have run clang-format on my changes (no C++ changed)
• I have run pre-commit run --all-files or installed pre-commit hooks (pre-commit run --files on both files: all passed, actionlint included)
• I have added tests that prove my fix/feature works (no new test: the steps were dry-run against fakes, and the release dry run below ran them for real)
• All new and existing tests pass
• I have updated documentation as needed

Testing

pre-commit run --files .github/workflows/release.yml CONTRIBUTING.md   # all passed
shellcheck -s bash <every new/changed bash step, and smoke-check.sh>    # clean
gh workflow run release.yml --ref ci/upgrade-from-0.8-2726 -f dry_run=true

Local dry runs: the steps' scripts were taken from release.yml with tests/tools/workflow_steps.py and run on Windows against fakes.

• Linux smoke-check.sh (Git Bash, with a fake TaskSmack script): the good run passes. Each of these fails with its own message: a lost setting (theme), no config_version, an [error] line, exit 1, and a missing fixture.
• "Start the upgraded TaskSmack" (with a fake dpkg): passes, reading $HOME/.config/tasksmack with TASKSMACK_CONFIG_DIR unset. A lost setting, no config_version, an [error] line and exit 1 each fail.
• Windows step (pwsh, with a fake TaskSmack.exe compiled from C#): the good run passes. A lost setting (font size), no config_version, an [error] line, exit 1, and a new %LOCALAPPDATA%\TaskSmack-dryrun-leak each fail.

Release dry run from this branch, first dispatch: https://github.com/mgradwohl/tasksmack/actions/runs/40211845017

Job	Result
Validate Linux Release Artifacts (x64)	✅ success: .deb and .tar.gz each passed both launches, and the v0.8.0 run saved size = 'large' and id = 'dracula'
Validate Linux Release Artifacts (arm64)	✅ success (same)
Validate Windows Release Artifacts (x64)	✅ success: llvmpipe, both launches, no trace
Validate Windows Release Artifacts (arm64)	✅ success (same)
Validate the Upgrade over v0.8.0's .deb (x64)	✅ success: the .deb matched the pin and the release digest; v0.8.0 ran for 5 s; Unpacking tasksmack (0.9.0) over (0.8.0); helper and policy are the new .deb's; no v0.8.0 file left over; the upgraded app quit cleanly with the settings kept
Validate the Installed Helper and Its polkit Policy (x64)	✅ success (unchanged)

Additional Notes

• Main-only, no backport: this builds on [CI] Clean-exit hook for smoke checks (assert config saved on exit) and a zip leave-no-trace check #2720's clean-quit hook, which is main-only, since release/0.9 lacks TASKSMACK_SCREENSHOT. So this is main-only too, with no backport:0.9 label. It's on v0.10.0; whether [CI] Upgrade-from-0.8 in the release validate jobs: apt-upgrade over v0.8.0's .deb, and seed the 0.8 config into the smoke launches #2726 moves off v0.9.1 is the maintainer's call.
• Edits release.yml: the maintainer approved it (poll, 2026-10-25).
• v0.8.0 isn't checked for a clean quit: it has no quit hook, so it's stopped with timeout -k 10 5. The step only requires that it was still running at 5 s (status 124, or 137 if it ignored the stop). Its own log isn't checked for [error].
• Two copies of the settings list: the seven fixture settings and the small toml_value awk reader are in both smoke-check.sh and the upgrade job. That's because the jobs run in different containers and nothing they share is checked out. Each copy has a "keep in step" comment, and the Windows step has its own copy.

🤖 Generated with Claude Code

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[mgradwohl]

Reviewed the new upgrade job: it has only read permissions, its actions are pinned by SHA, and v0.8.0's .deb is checked against both the pinned SHA-256 and the release's asset digest. Dry run 40211845017 passed every validate job, the upgrade included. Auto-merge is on. Whether #2726 moves to v0.10.0 is the maintainer's call, since this is main-only like #2720.