-
Notifications
You must be signed in to change notification settings - Fork 250
ci: fix cargo publish workflow #2505
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Remove readme field from Cargo.toml since the file doesn't exist and the crate is not published (publish = false).
When miden-utils-sync is declared with default-features = false in the workspace dependencies, cargo publish verification builds dependent crates without the std feature, causing OnceLockCompat to not be available. This fixes the CI failure where miden-core couldn't find OnceLockCompat during package verification.
| miden-utils-diagnostics = { path = "./crates/utils-diagnostics", version = "0.21", default-features = false } | ||
| miden-utils-indexing = { path = "./crates/utils-indexing", version = "0.21", default-features = false } | ||
| miden-utils-sync = { path = "./crates/utils-sync", version = "0.21", default-features = false } | ||
| miden-utils-sync = { path = "./crates/utils-sync", version = "0.21" } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this something that appeared recently? IIRC, we published v0.20 VM with default features turned off for miden-utils-sync.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change establishing std for miden-utils-sync is from the late innings of #2447.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still not sure I understand why this is happening. AFAICT, OnceLockCompat is exported from miden-utils-sync both in std and in no_std context (in no_std we export the wrapper around OnceBox). So, even with default-features = false it should work - no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, this is not reproducible for me locally. My hypothesis is that in CI, the dry-run :
- Packages each crate independently
- Verifies each package in isolation using a temporary registry
- This isolated verification context appears to have different feature resolution behavior than normal workspace builds.
Nonetheless, out of an abundance of caution, I'll close this.
567257b to
4458e5e
Compare
The workspace publish dry-run fails with `unresolved import
miden_utils_sync::OnceLockCompat` during verification. This happens
because cached registry data from previous CI runs can interfere with
cargo's temp registry used for workspace dependency resolution.
During verification, cargo should use the packaged v0.21.0 from the
temp registry, but stale cache entries may cause it to resolve
against crates.io data instead (where v0.20.1 lacks OnceLockCompat).
Clear ~/.cargo/registry/{cache,index,src} before the dry-run to ensure
fresh resolution without interference from cached data.
Closes #2505
c8e1833 is failing its
cargo publish --dry-run --workspacebecause of a menial time-of-pr versus time-of-merge issue. See commit messages.