generated from eblume/project-template
Pre-v1 cleanup: dependency-refresh sweep + drop fs4 + remove dead build hook #2
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feature/pre-v1-cleanup"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Pre-v1.0.0 cleanup sweep (the §14.9 dependency-refresh roadmap item, plus tooling tidy). All changes green locally; this PR's CI run validates the Linux build.
Dependency refresh (§14.9)
keyring_coresplit.KeyringTokenStorenow registers the OS-native store once (lazily, viaOnce) and useskeyring_core::{Entry, Error}.not_keyutils = trueso Linux prefers the Secret Service over the logout-wiped kernel keyutils store. Runtime behavior unchanged (tokens still go to the macOS Keychain / Linux Secret Service).cargo updatefor semver-compatible bumps across the rest. (pulldown-cmark, jsonwebtoken, axum, clap, tokio, reqwest were already latest.)Drop fs4 → std file locking
Rust stabilized
std::fs::File::try_lockin 1.89; the inherent method now shadows thefs4::FileExttrait, making fs4 a dead dependency. Removed it and switchedlock.rsto std. MSRV 1.85 → 1.89.Tooling
.forgejo/scripts/buildhook —build.yamlinvokes Dagger directly and never called it.Testing
cargo test --all— 228 passed, 0 failedmise run test-nvim— 25 headless e2e specs passedcargo clippy --all-targets --all-features -- -D warnings+cargo fmt --all --check— cleanWatch on CI
Validated on macOS. keyring 4 (no features) compiles in all platform stores by default, so the Linux Dagger build exercises the secret-service store crates for the first time — they appear pure-Rust (zbus, no system libdbus), so I expect green, but this CI run is the proof.
490a8b37630c502834c2The recent CI failures ("Cannot connect to the Docker daemon") are the DinD build engine being OOM-killed mid-compile, not flakiness. Serialize both the check and test_nvim cargo builds to jobs=1. Temporary mitigation pending more host RAM. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>