Repository navigation
fix: verify native update installation in CI and correct Windows signatures - #71
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Native update tests exposed a Windows signing defect: Builder signed the installer directly with DSA/SHA1, while both WinSparkle 0.8.1 and 0.9.4 verify DSA over SHA1(SHA1(installer)). The old Python validator repeated the same mistake. Fix both signing and validation to follow upstream's legacy protocol, with a native regression case rejecting the former single-hash signature.
The macOS regression test reproduces the 0.14.7 → 0.14.11 failure: a valid archive signature is rejected when the target bundle removes its Sparkle key. Packaging checks alone do not prove the updater can install and restart the app.
Add native Sparkle 2.8.1 / WinSparkle 0.8.1 and 0.9.4 lifecycle tests on macOS ARM64, macOS Intel and Windows x64. The 0.8.1 DLL exactly matches the one shipped in AppFlowy 0.14.7. An external controller serves signed fixture packages and observes installation, old-process exit, new-process launch and preserved test data. Negative cases cover the wrong signing key, Windows single-hash signatures, macOS key removal and skipping an update. PR tests use temporary keys and isolated storage, without release secrets.
Gate
auto_update.yamlappcast artifacts on installing the final signed release installer through the native engine, verifying the installed version/key/updater library, and keeping the real AppFlowy process alive for 15 seconds. Both Windows engines run this gate. AddtestOnly=trueto rehearse against draft or published releases without the version-configuration commit. Capture native events, HTTP requests, installer hash and logs on failure. Also fix macOS Bash 3.2 feed generation when optional metadata is absent: the argument array must remain nonempty underset -u.Scope: the release test uses an instrumented native source host with the deployed public key. It does not exercise Flutter/cloud discovery, consent UI, workspace migration, or candidate → N+1. Windows AppFlowy startup is explicitly controller-driven after Inno finishes, because the production installer has no relaunch entry. See
scripts/update_e2e/README.mdfor commands and limits.Validation:
testOnly=true.