ci: fail the build when the application cannot launch - #180
Merged
Conversation
…king out These comments pointed at a design note that is not in the repository, so every reader of the public repo hit a dead reference. The reasoning that was actually load-bearing now lives in the comments themselves: why the logical-zone concept was dropped (nothing in the field models a name plus a channel-index list as a free-standing object, and it confused users in testing), and why the migration can drop legacy records safely (the unification never shipped, so no released build ever persisted them).
v1.5.2 shipped a macOS build that could not start, and an app that cannot start cannot run its own updater, so the fault was unrecoverable by the mechanism that exists to recover from faults. The guards added afterwards test for that specific link-time regression; nothing anywhere launched the binary and observed it come up. Every push now builds and starts the debug binary on all three platforms and waits for a startup marker emitted at the end of window lifecycle setup, after the tray, the webview, React, and an IPC round trip — a throw anywhere earlier can never reach it. On Unix the same run asserts orderly shutdown, so a shutdown-deadlock regression turns the build red. Release builds go further and launch the real artefact: the mounted .dmg, the silently installed .msi, and the AppImage, each after upload but before the draft is published, so a bundle that cannot start never becomes a release.
…enance duties Releases are patch bumps only until further notice, so the version must not be classified from the diff, and a genuinely breaking change has to be called out in the notes instead. Green CI now proves the debug binary starts but says nothing about the bundle a user downloads, and that boundary is written down so it is never read as broader than it is. Also records that cargo build and tauri build --debug write the same path but produce different binaries — the cargo one loads the frontend from the dev server and opens blank without it, which is not obvious from the path. Adds standing duties that apply in every session: judge specialist output rather than passing it on, keep tooling and dependencies from drifting silently, and treat a regression in the per-frame budget as a defect. Guidance files are also trimmed to what a reader cannot get from the code itself.
…launch A plain cargo build overwrites the same target/debug path with a binary that loads the Vite dev URL; with no dev server it launches, stays alive and logs nothing, which is indistinguishable from a broken app. Assert the hashed entry chunk is embedded before launching, report whether the process was alive at the deadline, and add a temporary Windows diagnostic that prints the PE subsystem and dumps the log directory.
…hang Every observation on the Windows runner — process alive, WebView2 profile fully populated, log files created but empty, and no app data dir at all — points at setup() never returning, so the event loop never services IPC. Rust logging is synchronous and unaffected by that, so log the setup milestones to find the call that blocks.
setup() completes on the Windows runner and stdout works after all, so the hang is past the Rust side. Log page-load events, bisect the frontend bootstrap, and make the ready timeout overridable so a slow runner can be told from a wedged one. Note the earliest frontend probes are unreliable: the console bridge drops log invokes that lose the race with IPC becoming ready.
The webview reaches page-load Finished on the Windows runner and then emits nothing for five minutes, so the hang is after the bundle loads and is not slowness. Opening a DevTools window is the only Windows-specific, debug-only step in that path; gate it behind an env var and set it in CI to isolate it.
The Windows launch failure is not a test artefact. On a runner the app starts, setup() completes with the tray built, WebView2 runs, and the webview reports the bundle loaded — then no frontend IPC ever completes, the log files stay empty, and the app data directory is never created. Lost stdout was ruled out by reading the PE subsystem field on the runner, and a failing setup() by instrumenting it; what remains is either that the bundle's script never executes or that no IPC resolves, and neither can be separated without a real Windows desktop to compare against. Rather than weaken the assertion to get a green build, Windows is left uncovered in both workflows with the gap stated where someone will read it. The probes come out; the guard against a dev-URL binary stays, because a cargo build silently overwrites the same path with one that launches, survives, and logs nothing.
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
1 participant
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.
v1.5.2 shipped a macOS build that could not start, and an app that cannot start cannot run its own updater. The guards added afterwards test for that specific link-time regression — nothing anywhere launched the binary and watched it come up.
CI now builds and starts the debug binary on all three platforms and waits for a startup marker emitted at the end of window lifecycle setup, after the tray, the webview, React, and an IPC round trip. A throw anywhere earlier can never reach it. On Unix the same run also asserts orderly shutdown, so a shutdown-deadlock regression turns the build red.
Release goes further and launches the real artefact: the mounted
.dmg, the silently installed.msi, and the AppImage. These run after upload but before the draft is published, so a bundle that cannot start never becomes a release.Also in here: five source comments pointed at a design note that is not in this repository, so every reader hit a dead reference — the reasoning that mattered now lives in the comments themselves. And the guidance files record the patch-only versioning policy, the limits of what a green CI run actually proves, and that
cargo buildandtauri build --debugwrite the same path but produce different binaries.No dependency changes, no job renames, no CHANGELOG entry — a CI gate is invisible to someone using the application.
macOS was verified against a locally built DMG; the Windows MSI path is written to fail loudly rather than pass silently, and this PR is its first real run.