Configuration reference (`lading.toml`)

Version 0.3.1 Updated Sep 14, 2026

lading looks for lading.toml in the workspace root. The file must be a TOML table at the top level. Unknown keys are rejected with a configuration error.

All paths and globs are interpreted relative to the workspace root.

Complete example

[bump]
exclude = ["some-private-crate"]
lockfile_manifests = ["crates/nested/Cargo.toml"]
rebuild_lockfiles = true

[bump.documentation]
globs = ["README.md", "docs/**/*.md"]

[publish]
exclude = ["some-internal-tooling-crate"]
order = ["core", "utils", "app"]
strip_patches = "per-crate" # "all" | "per-crate" | false

[preflight]
skip = false
test_exclude = ["slow-integration-suite"]
unit_tests_only = false
aux_build = [["cargo", "+nightly", "test", "-p", "lint", "--no-run"]]
compiletest_extern = {
  ui_test_helpers = "target/debug/deps/libui_test_helpers.so"
}
env = { DYLINT_LOCALE = "en_GB" }
stderr_tail_lines = 40

`[bump]`

  • exclude: array of strings, default []. Crate names to exclude from manifest updates.
  • lockfile_manifests: array of strings, default []. Additional Cargo.toml manifests whose adjacent Cargo.lock files should be regenerated after lading bump. Git-tracked lockfiles are discovered and regenerated automatically. Configured manifests are needed for lockfiles that git does not track (for example, generated fixtures listed in .gitignore), and for all nested lockfiles when the workspace is outside a Git repository, where tracked-lockfile discovery cannot run at all. The workspace root Cargo.toml is always included and should not be listed.
  • rebuild_lockfiles: boolean, default true. Controls whether lading bump regenerates the workspace lockfile, discovered tracked lockfiles, and configured nested lockfiles after manifest updates. Pass --no-rebuild-lockfiles to skip regeneration for a single run, or --rebuild-lockfiles to force regeneration when rebuild_lockfiles is configured as false.

Lockfile regeneration runs cargo update --workspace --manifest-path <manifest> for the workspace root, each configured nested manifest, and each manifest adjacent to a discovered git-tracked lockfile. This updates workspace package entries while avoiding a full transitive dependency refresh.

Regeneration is not atomic, and lading bump attempts every manifest rather than stopping at the first Cargo failure. Manifest versions are written before any lockfile is refreshed, so a failure leaves the workspace inconsistent: the manifests carry the new version but the affected lockfiles do not. When several lockfiles are regenerated, lading raises one aggregated error that lists every failed manifest with the exact repair command to run:

Cargo lockfile regeneration failed for 2 manifest(s). Manifests already carry the new version, so the workspace is inconsistent until each lockfile below is repaired:
- Cargo lockfile regeneration failed for crates/a/Cargo.toml with exit code 101: <cargo error>
  cargo update --workspace --manifest-path crates/a/Cargo.toml
- Cargo lockfile regeneration failed for crates/b/Cargo.toml with exit code 101: <cargo error>
  cargo update --workspace --manifest-path crates/b/Cargo.toml

When one manifest was attempted, its lone failure surfaces the plain Cargo error instead. To recover, fix the underlying Cargo error and rerun lading bump, run the printed repair command for each listed manifest, or use --no-rebuild-lockfiles and regenerate the lockfiles manually before committing the bump.

`[bump.documentation]`

  • globs: array of strings, default []. Glob patterns for Markdown files whose TOML code fences should be updated.

`[publish]`

  • exclude: array of strings, default []. Crate names to exclude from publication.
  • order: array of strings, default []. Explicit publish order; overrides dependency-derived ordering when present.
  • strip_patches: one of "all", "per-crate", or false; default "per-crate". Controls how [patch.crates-io] is edited in the staged workspace before packaging.

Observability

When lading runs, a structured JSON summary may appear in the log output at INFO level just before the process exits. The flush is process-wide — any command can emit it — and reports whichever metrics that run recorded. For example, a publish run that downgraded an index-lookup failure emits:

lading metrics summary: [{"metric": "publish.index_lookup_downgrade", "labels": {"missing_crate": "...", "subcommand": "..."}, "value": 1}]

Each entry records a counter name, the label values that identify it, and the accumulated count for the current invocation. The summary line is omitted entirely when no metrics were recorded (quiet runs stay quiet).

publish.cargo.duration

One duration observation per cargo package or cargo publish invocation in the publish pipeline, recorded whether or not the invocation succeeded. Labels:

  • subcommand — package or publish.
  • crate — the crate the invocation ran for.

publish.preflight

Incremented once per lading publish run when the pre-flight resolves, including when it fails. Labels:

  • mode — skipped or executed.
  • source — configuration, command-line, environment, or in-process; the input that decided mode. The last covers a caller that drives the command in process rather than through a parsed command line.

publish.preflight.duration

One duration observation per lading publish run, covering the whole pre-flight, recorded whether or not it succeeded. Labels:

  • mode — skipped or executed, which makes the saving from a skip directly comparable.
  • source — the same values as publish.preflight, so a skip requested by the environment is distinguishable from one the configuration asked for.

publish.sccache.query

Incremented once per sccache statistics query while the instrumentation is on (--sccache-stats, or a --sccache-stats-json path, which implies it). Labels:

  • outcome — success or failure; a failure also disables further queries for the rest of the run.

publish.index_lookup_downgrade

Incremented on each downgrade event when a crates.io index-lookup failure for a sibling workspace dependency is downgraded to a warning because allow_unpublished_workspace_deps is enabled. Labels:

  • subcommand — the Cargo subcommand that failed (package or publish).
  • missing_crate — the name of the workspace dependency absent from the index.

`[preflight]`

  • skip: boolean, default false. Skip the pre-flight auxiliary builds, cargo check, and cargo test because the caller has already verified the workspace. The Cargo.lock freshness check always runs, and the working-tree cleanliness check runs whenever --forbid-dirty opted into it. See Skipping a pre-flight the caller has already run.
  • test_exclude: array of strings, default []. Crate names to exclude from cargo test by passing --exclude.
  • unit_tests_only: boolean, default false. Append --lib --bins to the pre-flight cargo test invocation.
  • aux_build: nested array of strings, default []. Extra tokenized commands to run before cargo pre-flight checks.
  • compiletest_extern: table of string keys and values, default {}. Extra --extern entries to append to RUSTFLAGS for compiletest-style suites.
  • env: table of string keys and values, default {}. Environment overrides applied to git/cargo invocations run by publish.
  • stderr_tail_lines: integer greater than or equal to zero, default 40. Number of lines to tail from referenced *.stderr files when tests fail.