Guardrails / rust

Cargo dependencies are locked

rust/lockfile-committed@v1

The build commits Cargo.lock, so a rebuild of the same commit resolves the same crate versions.

Id	rust/lockfile-committed
Version	v1
Category	rust
Default severity	warning
Interpreter	python3
Timeout	30 seconds
Violations tolerated	0
Collects	rust

Collectors

This guardrail doesn't gather anything itself. It relies on the collectors below, which the CLI runs once per build before any check, and reads what they found from GUARDRAIL_FACTS. If a collector collects nothing, this guardrail is skipped, not failed.

Collector	Gathers	Inputs it is given
rust	The Cargo build in the project directory: the crate it declares, the Rust version and edition it asks for, every workspace member, the dependencies each manifest names with where each comes from and whether it is pinned, and the lock file beside them.	projectDir

The inputs above are this guardrail's own inputs, passed straight through to the collector. Setting one in buildnote.json changes what is collected, and two guardrails configured the same way share a single collection.

Configuration

{
  "guardrails": {
      "failOn": "error",
      "checks": [
          {
              "use": "rust/lockfile-committed@v1",
              "severity": "warning",
              "with": {
                  "projectDir": "."
              },
              "exemptions": []
          }
      ]
  }
}

Inputs

Input	Description	Default	Environment variable
projectDir	Directory holding the project, relative to the directory the CLI runs in.	.	GUARDRAIL_INPUT_PROJECTDIR

How to fix

Commit the lock file Cargo writes next to the manifest:

cargo generate-lockfile
git add Cargo.lock

A bare 1.0.197 is a caret requirement that matches every compatible release. Without a lock file, a rebuild resolves whatever the registry serves that day, and the binary that shipped is not the one that was reviewed. The lock file only pins this build: Cargo ignores a library's own Cargo.lock when another crate depends on it, so committing one keeps CI stable but doesn't affect anything downstream.

More in rust

• rust/edition-floor. The package declares a Rust edition instead of falling back to the implied 2015 edition, and that edition is no older than the configured floor.
• rust/no-git-dependencies. No manifest declares a dependency with a git source, so every crate in the build comes from a registry that versions it.
• rust/version-declared. The build names the Rust toolchain it compiles with. The toolchain is an exact release, not a moving channel, and it is no older than the configured floor.

All 4 rust guardrails