Skip to content

continuous integration

Kadyapam edited this page Oct 3, 2026 · 1 revision

Continuous Integration

.github/workflows/test.yml is this crate's pre-merge gate. It runs on pull_request and on pushes to main.

step command
build cargo build --workspace --all-targets --locked
test cargo test --workspace --all-targets --locked
doctests cargo test --workspace --doc --locked
clippy cargo clippy --workspace --all-targets --locked -- -D warnings

--all-targets and the separate --doc run

Both spellings are load-bearing.

--all-targets — plain cargo build / cargo test skip integration tests and cfg(test)-only code, so a binary or a test can be broken while the library compiles clean.

--doc as its own step — ⚠ --all-targets EXCLUDES doctests. This crate's doctests were therefore never run by CI, and one of them had been failing to compile on main: src/tools/shell.rs had example output in an indented block, which rustdoc treats as Rust. cargo test exited 101 locally while CI stayed green. A separate --doc run is the only way this gate can see them.

clippy gates, with no allow-list

As of noetl/ai-meta#378 the clippy step uses -D warnings and has no -A exceptions. A new lint of any kind fails the build.

It previously ran as cargo clippy … || true, which meant the step appeared in every PR log and could never fail. That was not arbitrary neglect: three pre-existing question_mark lints in src/arrow_codec.rs would have made a bare flip start red for reasons no individual PR caused. They were fixed first (} else if let Some(x) = e { … } else { return None } → } else { let x = e?; … }, which is equivalent because try_encode_tabular_json returns Option), then the gate was flipped.

If you need to add an -A, add the reason on the same line. An unexplained -A reads as configuration rather than as debt, and nothing ever revisits it. server and cli both carry reasoned allow-lists for this purpose; this crate carries none, and keeping it that way is cheaper than paying it back later.

⚠ The lint set floats — there is no toolchain pin

This repo has no rust-toolchain.toml, and the workflow installs dtolnay/rust-toolchain@stable. clippy's lint set therefore moves with every Rust release, so main can turn red with no code change.

This is observable, not theoretical — a CI run on 2026-10-03 logged, mid-run:

stable-x86_64-unknown-linux-gnu updated - rustc 1.99.0 (b940084d7 2026-09-28)
  (from rustc 1.98.1 (48a229cea 2026-09-01))

A practical consequence: a local cargo clippy green is not evidence about CI. A local 1.97.1 and a CI 1.99.0 run different lint sets. Read the result off the PR.

noetl/gateway and noetl/cli pin 1.91.1; adding a pin here is tracked on noetl/ai-meta#378.

Releases are not triggered by this workflow

semantic-release.yml owns the version. A merge subject of fix: cuts a patch, feat: a minor; ci: and chore: release nothing, silently. If a change needs to reach a consumer, it needs a release-triggering type — and the tag should be read back after the merge rather than assumed.

Related

Clone this wiki locally