test's own compiled objects are worth reusing across runs — it's the
only job needing full codegen, so it can't share anything with the
clippy jobs' check-only builds regardless of key. Scoping it to a key
the clippy jobs don't touch avoids the contention/collision problem
that came from all 5 jobs previously sharing one target/ cache key,
and since it excludes feedsignal-web, its target/ stays much smaller
than the combined cache removed earlier.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
target/ was the majority of the ~1.5GB cache each of the 5 CI jobs
tarred and uploaded on every run — expensive on a single runner where
those uploads contend for the same disk/network, and pointless since
these jobs build different feature-set combinations into one
identically-keyed target dir anyway. sccache already gives compiler-
level reuse without that duplication.
sccache's cache key was keyed to github.run_id, which never gets an
exact hit, so its ~377MB also re-uploaded in full every single run
with no benefit. Key it to Cargo.lock like the registry cache instead,
so it only re-saves when dependencies actually change.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The single "check" job ran fmt + four clippy variants (native, server,
web, desktop) as sequential steps, so the desktop feature's clippy check
always waited on the other three even though none of them share
dependencies. Splitting each into its own job lets the runner (capacity
2) run them concurrently instead.
Also drops the per-run `apt-get install` for the GTK/WebKit headers
dioxus-desktop needs — those are now baked into a dedicated
`rust-ci-desktop` runner image (schaefera/infrastructure#TBD) so only the
desktop job's image is bigger, not every job's.
Depends on the `rust-ci-desktop` label being registered on the ci-runner
box before this workflow's clippy-desktop job can pick up work.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Combines dioxus's desktop (webview) renderer with the existing `server`
feature so `#[server]` functions execute in-process instead of going over
HTTP — one self-contained native binary with DB, feed polling, LLM calls,
and the scheduler, no separate server to run. main.rs picks the desktop
launcher explicitly since dioxus::launch's automatic platform detection
would otherwise prefer the (also-enabled) server platform over desktop.
Verified: cargo check/clippy pass for the new feature (native crates and
existing server/web features unaffected), and running the built binary
opens a window and completes an in-process server-fn call (DB connects,
migrations run) with no HTTP round trip. CI gets a matching desktop
clippy job with the GTK/WebKit apt packages dioxus-desktop needs to
compile on Linux.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
cargo clippy --all-targets already type-checks everything cargo check
would, so running both for each of the three feature/target
combinations was roughly doubling compile time in this job.
Switches from the docker/rust:1-bookworm container back to the rust-ci
runner label, and adopts sporah's build/test/audit job split with
cargo registry + sccache caching. Keeps feedsignal's workspace-specific
checks (native crates, web crate server/wasm-client features) and adds
clippy + cargo audit, which were previously missing.
Rust workspace with core (topic-affinity learning engine + relevance
scoring), db (sqlite/sqlx schema + repo), feeds (RSS/Atom fetch), llm
(rig + local Ollama embeddings/completion), and web (axum + Dioxus
fullstack UI, no separate JS stack). Two-stage relevance filtering
(embedding shortlist -> LLM judgment) and an engagement/surprise-based
topic affinity engine with daily decay. All crates compile and core's
affinity engine has passing unit tests; server and wasm client targets
of feedsignal-web both check clean.
