Summary
.github/workflows/ci.yml only runs release-plz and Docker image builds. There is no job that runs cargo test, cargo clippy, or cargo fmt --check. The Dockerfile compiles the binary (cargo build --profile ${CARGO_PROFILE} --bin cryptify) but never runs the test suite.
Impact
- A test regression can merge to
main without any signal — the codebase has a non-trivial test suite (src/main.rs mod tests, src/store.rs mod tests, src/email.rs mod tests) which is currently only validated by humans running cargo test locally.
cargo fmt --all -- --check currently fails on the working tree (drift in email.rs, error.rs, main.rs); CI cannot catch this.
- Sister repo
ibe already runs a fmt check in CI — this repo is the outlier.
Suggested approach
Recommend splitting into a small sequence so the test job can land green:
- Format pass:
cargo fmt --all as a standalone PR (no logic changes).
- Clippy pass: address pre-existing warnings (e.g. the
useless format! in email.rs) in a small PR. If any are intentional, #[allow(...)] with a comment.
- Add CI job that runs:
cargo fmt --all -- --check
cargo clippy --all-targets -- -D warnings
cargo test --all-targets
The job should run on pull_request and push: main, on ubuntu-latest, with Swatinem/rust-cache for speed. It should NOT block the existing release-plz/Docker workflow — add it as a separate job that runs in parallel.
Flagging for human review on sequencing — workers tend to bundle these together which makes the resulting PR hard to review.
Summary
.github/workflows/ci.ymlonly runsrelease-plzand Docker image builds. There is no job that runscargo test,cargo clippy, orcargo fmt --check. The Dockerfile compiles the binary (cargo build --profile ${CARGO_PROFILE} --bin cryptify) but never runs the test suite.Impact
mainwithout any signal — the codebase has a non-trivial test suite (src/main.rsmodtests,src/store.rsmodtests,src/email.rsmodtests) which is currently only validated by humans runningcargo testlocally.cargo fmt --all -- --checkcurrently fails on the working tree (drift inemail.rs,error.rs,main.rs); CI cannot catch this.ibealready runs a fmt check in CI — this repo is the outlier.Suggested approach
Recommend splitting into a small sequence so the test job can land green:
cargo fmt --allas a standalone PR (no logic changes).useless format!inemail.rs) in a small PR. If any are intentional,#[allow(...)]with a comment.cargo fmt --all -- --checkcargo clippy --all-targets -- -D warningscargo test --all-targetsThe job should run on
pull_requestandpush: main, onubuntu-latest, withSwatinem/rust-cachefor speed. It should NOT block the existing release-plz/Docker workflow — add it as a separate job that runs in parallel.Flagging for human review on sequencing — workers tend to bundle these together which makes the resulting PR hard to review.