fix(headless): no Tauri, and so no GTK, in a browser with no window - #40
Merged
Conversation
added 2 commits
September 9, 2026 17:01
`cargo build --bin chuzz-headless` failed on a Linux runner with
The system library `glib-2.0` required by crate `glib-sys` was not found.
Dependencies are per package, not per binary, so the headless binary compiled
the whole of `chuzz-gui`'s graph. `default-features = false` on `tauri` was
not enough, and could not be: the path is not the webview.
glib-sys <- atk <- gtk <- muda <- tauri
gtk <- webkit2gtk <- tauri-runtime
`muda` is Tauri's menu crate and `tauri-runtime` names WKWebView types in its
public API, so both are unconditional. Same shape as the `objc2-web-kit` note
in build.rs, which is about the macOS end of the same fact.
`tauri-runtime-blitz` already anticipated this: its `runtime` feature gates
Tauri, and its own comment says that off it, "a headless consumer gets the
inspection and activation surface with no Tauri in its graph, which on Linux is
the difference between a build and GTK development headers for a binary that
never opens a window". This workspace was taking it with defaults and getting
the window stack it does not use.
So `gui` is now a feature: `dep:tauri` and `tauri-runtime-blitz/runtime`, with
`browser`, `frontend` and the `chuzz-gui` binary behind it, and `tauri_build`
gated in build.rs because the context it generates has nothing to describe
without them. Default keeps it on, so an ordinary build is unchanged.
`source_html` moved to a new `internal_pages` module. It is a pure string
function that `document_loader` and `capture` both call, and it was the only
thing keeping `browser` in the headless graph. View source and the error page
are pages rather than chrome, so that is where they belonged anyway.
Verified against the Linux target: `cargo tree -i glib-sys` and `-i tauri` both
report no such package in the headless graph, and the GUI binary still builds.
0.1.37 rather than a second pull request: the action changes how consumers
build the host and the feature split changes what ships, so they are one
release.
The lockfile commit removed a comment paragraph above the frontend install
step and took the step's indentation with it, leaving
- name: Install frontend dependencies
twelve spaces deep inside a six-space block. GitHub rejects the file before
running anything:
This run likely failed because of a workflow file issue.
So 0.1.36 was merged, tagged in the manifest, and never published: the release
job could not start. A bump with a broken workflow is not a release, and the
failure names the file rather than the line, which is why it read as an
infrastructure problem rather than a typo.
Every workflow and action in this repository now parses.
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.
Every site's QA job dies building the host on Linux:
Dependencies are per package, not per binary, so
--bin chuzz-headlesscompiled all ofchuzz-gui's graph.default-features = falseontaurinever helped, because the path is not the webview:mudais the menu crate andtauri-runtimenames WKWebView types in its public API. Both unconditional.tauri-runtime-blitzalready had the answer. Itsruntimefeature gates Tauri and its comment says off it a headless consumer gets the inspection surface "with no Tauri in its graph, which on Linux is the difference between a build and GTK development headers". We were taking defaults.Change:
guifeature =dep:tauri+tauri-runtime-blitz/runtime, withbrowser,frontend, thechuzz-guibin andtauri_build::build()behind it. On by default, so an ordinary build is unchanged.source_htmlmoved to a newinternal_pagesmodule, since it was the only thing keepingbrowserin the headless graph.Verified on the Linux target:
cargo tree -i glib-sysand-i tauriboth report no such package; GUI binary still builds; fmt and clippy clean.Includes the 0.1.37 bump rather than a follow-up PR.