Ability to verify my cargo workspace before packaging but without building.

[eirnym]

Problem

Currently packaging verification process run by cargo package and cargo publish runs 2 tasks:

1. Metadata verification.
2. Build a package

First task is just cargo build, the second may emit warnings about some metadata is missing

Good practice on CI is to run sequentially or in parallel

1. Run fast metadata verification, as this process will take short time and it's important. No build required.
2. Build project and run all checks to verify if even some wrong commit was merged, release would be clean

The metadata verification is done by cargo package and if critical field is missing, a warning is emitted. There's no control on which metadata is critical, which is not and there's no way to enforce it.

Additionally, building a package in most cases is a duplication of responsibility of a user to run at least cargo build first.

I understand historical reasons of this solution in cargo package, and I'd like to have an ability to alter this behaviour on demand/company policies, but not remove this step completely

Previous discussion was here: #15398

Proposed Solution

For making build optional I'd like to have configuration variable to be set to control behaviour of cargo verification process.

Notes

No response

[epage]

I'm sorry; I'm a bit confused with this issue. Parts read that you want to disable the build that happens with cargo package while others that you want control over the warnings.

For disabling the build, that is what the --no-verify flag does. Note that this is not the same as cargo build as it makes sure the generated .crate can be built. Most metadata is "set and forget" but what is needed for building a package is likely the most brittle part as you develop your package. For more discussion on customizing the verify step, see https://blog.rust-lang.org/inside-rust/2025/01/17/this-development-cycle-in-cargo-1.85/#cargo-publish-verify-behavior, #14685, and #14941.

As for controlling the warnings, existing issues we have for this include #4840, #4377, and #8221. Most of this is likely blocked on #12235.

[weihanglo]

I was expecting to keep this open separately and tracked by #12235.