No CI — nothing verifies builds, tests, feature combinations, or determinism #24

New Issue

2026-08-04T19:21:02Z

logaritmisk commented

2026-08-04 19:21:02 +00:00

There is no .github/workflows/, no .gitea/workflows/, and no CI configuration of any kind in the repo. Every check is run by hand.

That is doing real damage. The bugs filed today (#8, #9, #11, #19) all reproduce in a plain cargo test --release, and #8's root cause is guarded by a debug_assert! that a debug-only test run would have caught — but nothing runs either automatically.

What CI needs to cover

The feature matrix is the important part. This crate has behaviour that only exists under specific combinations:

Job	Why
`cargo build` / `cargo test` (no features)	The default build most consumers get
`cargo test --features approx`	Most numerical goldens need it — `assert_ulps_eq`
`cargo test --features approx,rayon`	The parallel path, including `tests/determinism.rs`
`cargo test --release --features approx`	Critical: `debug_assert!`s vanish here, and that is where #8 and #18 live. Debug-only testing hides an entire class of defect in this codebase
`cargo clippy --all-targets --all-features -- -D warnings`	Currently clean; keep it that way
`cargo +nightly fmt --check`	`rustfmt.toml` exists and nightly is required for it
`tests/determinism.rs` at `RAYON_NUM_THREADS={1,2,4,8}`	The bit-identical guarantee from #2's PR is only meaningful if it's checked continuously
`cargo test --doc`	Once doc examples exist — see #25

Worth adding as follow-ups once the basics are green: cargo +nightly miri test for #13's aliasing question, and a cargo bench regression check against benches/baseline.txt (which is committed but compared manually).

Supporting gaps

Justfile only has bench recipes (store, bench, flame). No test, lint, fmt, or check recipe, so there is no single local command that mirrors what CI would run. Adding those makes CI a thin wrapper over the same recipes.
Cargo.lock is gitignored (.gitignore:2). For libraries this used to be the convention, but the current Cargo guidance is to commit it for all packages — CI is reproducible, and cargo still ignores it for downstream dependents. Without it, a CI failure can't be reproduced locally at the same dependency versions.
No MSRV declared — so no job can meaningfully test the oldest supported toolchain. See #25.

Acceptance

A CI workflow runs the matrix above on push and PR.
The release-mode job is present and non-optional.
just test / just lint / just fmt exist and CI calls them.

There is no `.github/workflows/`, no `.gitea/workflows/`, and no CI configuration of any kind in the repo. Every check is run by hand. That is doing real damage. The bugs filed today (#8, #9, #11, #19) all reproduce in a plain `cargo test --release`, and #8's root cause is guarded by a `debug_assert!` that a debug-only test run would have caught — but nothing runs either automatically. ## What CI needs to cover The feature matrix is the important part. This crate has behaviour that only exists under specific combinations: | Job | Why | |---|---| | `cargo build` / `cargo test` (no features) | The default build most consumers get | | `cargo test --features approx` | Most numerical goldens need it — `assert_ulps_eq` | | `cargo test --features approx,rayon` | The parallel path, including `tests/determinism.rs` | | `cargo test --release --features approx` | **Critical**: `debug_assert!`s vanish here, and that is where #8 and #18 live. Debug-only testing hides an entire class of defect in this codebase | | `cargo clippy --all-targets --all-features -- -D warnings` | Currently clean; keep it that way | | `cargo +nightly fmt --check` | `rustfmt.toml` exists and nightly is required for it | | `tests/determinism.rs` at `RAYON_NUM_THREADS={1,2,4,8}` | The bit-identical guarantee from #2's PR is only meaningful if it's checked continuously | | `cargo test --doc` | Once doc examples exist — see #25 | Worth adding as follow-ups once the basics are green: `cargo +nightly miri test` for #13's aliasing question, and a `cargo bench` regression check against `benches/baseline.txt` (which is committed but compared manually). ## Supporting gaps - **`Justfile` only has bench recipes** (`store`, `bench`, `flame`). No `test`, `lint`, `fmt`, or `check` recipe, so there is no single local command that mirrors what CI would run. Adding those makes CI a thin wrapper over the same recipes. - **`Cargo.lock` is gitignored** (`.gitignore:2`). For libraries this used to be the convention, but the current Cargo guidance is to commit it for all packages — CI is reproducible, and `cargo` still ignores it for downstream dependents. Without it, a CI failure can't be reproduced locally at the same dependency versions. - **No MSRV declared** — so no job can meaningfully test the oldest supported toolchain. See #25. ## Acceptance - A CI workflow runs the matrix above on push and PR. - The release-mode job is present and non-optional. - `just test` / `just lint` / `just fmt` exist and CI calls them.

logaritmisk referenced this issue

2026-08-04 19:21:19 +00:00

`cargo publish` would fail: no `description`, `license`, or `repository` — and the crate has no top-level docs #25

logaritmisk referenced this issue

2026-08-04 19:21:40 +00:00

Test suite has no coverage for degenerate inputs, release-mode behaviour, or non-finite results #26

logaritmisk commented

2026-08-04 20:12:16 +00:00

Added in 9506fed: .gitea/workflows/ci.yml, covering the matrix above — default / approx / approx,rayon / --release, plus clippy with warnings denied, nightly fmt --check, doc tests, determinism at RAYON_NUM_THREADS 1/2/4/8, and an MSRV job.

The release job earns its place immediately: debug_assert! is compiled out there, which is exactly where #8's tie/p_draw validation and #18's boundary checks have to hold. A debug-only suite would not have seen any of it.

The Justfile gained test, check, lint, fmt, fmt-check, determinism and ci, so the same checks run locally with one command and CI is a thin wrapper over them.

MSRV is declared as 1.85 (the edition-2024 floor) and verified by its own job. Two let-chains I had introduced earlier on this branch would have pushed it to 1.88; they were rewritten to keep the floor where it was.

Two caveats:

The workflow has never executed. It targets Gitea Actions and is written against actions/checkout@v4, dtolnay/rust-toolchain and Swatinem/rust-cache@v2; if Actions is not enabled on this instance, or the action mirror differs, it will need adjusting on first run.
Cargo.lock is still gitignored, so CI resolves fresh dependencies each run and a failure there may not reproduce locally at the same versions. Current Cargo guidance is to commit it for libraries too. Left alone as it is a deliberate-looking choice — worth revisiting.

Added in 9506fed: `.gitea/workflows/ci.yml`, covering the matrix above — default / `approx` / `approx,rayon` / `--release`, plus clippy with warnings denied, nightly `fmt --check`, doc tests, determinism at `RAYON_NUM_THREADS` 1/2/4/8, and an MSRV job. The release job earns its place immediately: `debug_assert!` is compiled out there, which is exactly where #8's tie/`p_draw` validation and #18's boundary checks have to hold. A debug-only suite would not have seen any of it. The `Justfile` gained `test`, `check`, `lint`, `fmt`, `fmt-check`, `determinism` and `ci`, so the same checks run locally with one command and CI is a thin wrapper over them. MSRV is declared as 1.85 (the edition-2024 floor) and verified by its own job. Two let-chains I had introduced earlier on this branch would have pushed it to 1.88; they were rewritten to keep the floor where it was. Two caveats: - **The workflow has never executed.** It targets Gitea Actions and is written against `actions/checkout@v4`, `dtolnay/rust-toolchain` and `Swatinem/rust-cache@v2`; if Actions is not enabled on this instance, or the action mirror differs, it will need adjusting on first run. - **`Cargo.lock` is still gitignored**, so CI resolves fresh dependencies each run and a failure there may not reproduce locally at the same versions. Current Cargo guidance is to commit it for libraries too. Left alone as it is a deliberate-looking choice — worth revisiting.

logaritmisk referenced this issue

2026-08-04 20:12:32 +00:00

`cargo publish` would fail: no `description`, `license`, or `repository` — and the crate has no top-level docs #25

logaritmisk referenced this issue

2026-08-04 20:13:26 +00:00

Test suite has no coverage for degenerate inputs, release-mode behaviour, or non-finite results #26

logaritmisk closed this issue

2026-08-04 20:13:50 +00:00

logaritmisk referenced this issue

2026-08-27 15:43:51 +00:00

`cargo publish` would fail: no `description`, `license`, or `repository` — and the crate has no top-level docs #25

logaritmisk added the infra testing labels 2026-09-07 13:53:26 +00:00