ci: build the desktop shell on macOS as well as Linux - #12
Merged
Conversation
`cargo fmt --all -- --check` and `cargo clippy -D warnings` both failed on
main under rustc 1.97.1. No source change caused this: `useless_concat` and
`unneeded_struct_pattern` are recent clippy lints, and CI pins nothing.
Three clippy fixes, all in test code and all semantics-preserving:
- codex.rs: two single-argument `concat!(..)` calls collapsed to plain
string literals (clippy::useless_concat).
- ingest_file.rs: `IngestOutcome::Skipped { .. }` -> `IngestOutcome::Skipped`;
it is a unit variant (clippy::unneeded_struct_pattern).
Then `cargo fmt --all`, which rewrapped 18 over-width assertion lines across
the two adapters, adapters/common.rs, and four integration tests. Mechanical
line-wrapping at the 100-column limit only.
No production code touched. Verified green: fmt, clippy (lore-core/lore-ipc
and lore-app), cargo test --locked --all-targets (346 pass / 4 ignored),
no_network_in_archive, no_egress, egress-check.sh, IPC bindings in sync,
npm lint/typecheck/test (148 pass).
Follow-up: pinning the toolchain so this cannot recur.
CI ran `dtolnay/rust-toolchain@stable` with `cargo clippy -- -D warnings`, so
any new lint in a stable release broke the build on a commit that changed
nothing. That is not hypothetical: it is exactly how main went red under
1.97.1 (previous commit). Pinning turns a toolchain upgrade into an explicit,
reviewable change.
- rust-toolchain.toml pins 1.97.1 with rustfmt/clippy and the minimal
profile. rustup honors it for every cargo invocation, locally and in CI.
- Both workflows now reference dtolnay/rust-toolchain@1.97.1 rather than
@stable, so the runner pre-installs the same compiler rustup would fetch
(the action does not read rust-toolchain.toml — verified against its
README; @1.97.1 is a valid ref).
- scripts/toolchain-pin-check.sh fails if the toml channel, the workflow
action refs, and the active rustc are not all the same version. Wired in
as the first step of the rust-core job, ahead of fmt/clippy. Verified it
passes when aligned and fails when the toml and workflows disagree.
This is not the MSRV. `rust-version = "1.90"` in Cargo.toml still declares the
minimum supported compiler; this pins the one we build and lint with.
Verified: pin check, fmt, clippy (both invocations), cargo test --locked
--all-targets (346 pass / 4 ignored), both workflow files parse as YAML.
macOS is the only platform we ship — release.yml builds an Apple Silicon .dmg
and nothing else — but the desktop-shell job ran on ubuntu-latest only. The
shipping target was therefore first compiled at tag time, which is the worst
moment to discover a macOS-specific break: the release is already cut.
desktop-shell becomes a matrix over ubuntu-latest and macos-latest:
- fail-fast: false, so a macOS-only failure is not hidden behind the faster
Linux job.
- The apt-get step is gated on `runner.os == 'Linux'`. macOS needs no
equivalent — WebKit ships with the OS and the Xcode command-line tools are
preinstalled on the runner image.
Every other step is platform-independent and unchanged.
Verified by running the macOS lane's exact steps on an Apple Silicon machine:
npm ci/build, `cargo clippy -p lore-app --all-targets -- -D warnings`,
`cargo build --locked -p lore-app`, and `cargo test -p lore-app --test
no_egress` all pass, producing target/debug/Lore as a Mach-O 64-bit arm64
executable.
This covers compilation, not bundling. `tauri build` (.app/.dmg, ~release-mode)
is still only exercised on a tag — though release.yml already has
workflow_dispatch, so it can be run on demand without cutting a release.
hsusul
force-pushed
the
ci/macos-shell-lane
branch
2 times, most recently
from
August 22, 2026 21:56
f0ef10c to
10cd462
Compare
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.
Problem
release.ymlbuilds an Apple Silicon.dmgand nothing else. macOS is the only platform Lore ships. But thedesktop-shellCI job ran onubuntu-latestonly, so the shipping target was first compiled at tag time — the worst possible moment to find a macOS-specific break, because the release is already being cut.Change
desktop-shellbecomes a matrix overubuntu-latestandmacos-latest.fail-fast: false— a macOS-only failure shouldn't be hidden behind the faster Linux job finishing first.apt-getstep is gated onrunner.os == 'Linux'. macOS needs no equivalent: WebKit ships with the OS and the Xcode command-line tools are preinstalled on the runner image.Every other step is platform-independent and unchanged. Linux stays in the matrix — it's the cheap lane, and it keeps the non-macOS webview path honest for the eventual Windows/Linux builds on the V1 roadmap.
Verification
I ran the macOS lane's exact steps on an Apple Silicon machine rather than guessing they'd work:
npm ci && npm run buildcargo clippy -p lore-app --all-targets -- -D warningscargo build --locked -p lore-appcargo test -p lore-app --test no_egresstarget/debug/Lore— Mach-O 64-bit executable arm64Scope limit
This covers compilation, not bundling.
tauri build(the.app/.dmgbundle, release mode) is still only exercised on a tag. I left it out of per-PR CI deliberately — it's a release-mode build on every pull request, which is a large cost for a path that changes rarely.Worth knowing:
release.ymlalready hasworkflow_dispatch, so the full bundle can be built on demand from the Actions tab without cutting a release. That's the cheap way to close the remaining gap before shipping.