mirror of
https://github.com/freemkv/freemkv-keysources.git
synced 2026-10-07 18:13:11 +00:00
Matthew Jackson
ca60c8fe1c
Two things were wrong here. `cargo test --locked` could never pass. Cargo.lock is gitignored for this crate (library convention), so there is no committed lockfile to lock against and cargo refuses to create one — every run failed before compiling a line. That is the immediate red. The deeper problem is what the workflow was building against. The committed Cargo.toml resolves libfreemkv from a git tag, so CI compiled this branch against the LAST RELEASE of libfreemkv and never against libfreemkv's dev tip. A change spanning the two repos could not be verified until release.sh cut the tags — at which point a break is discovered in the middle of shipping. Green meant "compiles against last month's library". Now each repo is checked out into a subdirectory of the workspace, reproducing the local ~/Developer/freemkv layout, and a generated .cargo/config.toml redirects the git-tag patch at those paths. That is the same config-level [patch.crates-io] mechanism local development already uses, and it wins over the manifest patch. Subdirectories because actions/checkout refuses a path: outside $GITHUB_WORKSPACE. Nothing in the manifests or the release cascade changes. Adds macOS and Windows jobs: this crate ships wherever freemkv and autorip ship and drags in all of libfreemkv's platform code, and neither OS was compiling it outside a release build. clippy gains --all-targets, which is what turned up the manual str::repeat in keydb_format's round-trip test — test code had never been linted.