cargo-release
cargo-release copied to clipboard
Waiting for publish to complete...
Just did a first-time release of a crate to crates.io:
$ cargo release --execute
Release unleash-proxy 0.1.0? [y/N]
y
[2022-03-04T20:06:19Z INFO cargo_release::release] Publishing unleash-proxy
Updating crates.io index
Packaging unleash-proxy v0.1.0 (/home/robertc/src/cognitedata/unleash-proxy-rust)
Verifying unleash-proxy v0.1.0 (/home/robertc/src/cognitedata/unleash-proxy-rust)
Compiling version_check v0.9.4
Compiling proc-macro2 v1.0.36
...
Compiling unleash-api-client v0.6.0
Compiling unleash-proxy v0.1.0 (/home/robertc/.../unleash-proxy-0.1.0)
Finished dev [unoptimized + debuginfo] target(s) in 46.67s
Uploading unleash-proxy v0.1.0 (/home/robertc/.../unleash-proxy-rust)
[2022-03-04T20:07:07Z INFO cargo_release::cargo] Waiting for publish to complete...
[2022-03-04T20:12:07Z ERROR cargo_release] Fatal: Timeout waiting for crate to be published.
$
The publish had completed, verified by hitting crates.io several minutes earlier.
The publish timeout occurred when I went to attach strace to the process. Perhaps I got lucky and that sub-second race was coincidence :P.
$ ps fax | grep cargo
24679 pts/0 S+ 0:00 | \_ /home/robertc/.cargo/bin/cargo-release release --execute
30601 pts/1 S+ 0:00 \_ grep --color=auto cargo
$ strace -p 24679
strace: attach: ptrace(PTRACE_SEIZE, 24679): No such process
Having the same issue. Crate is available almost immediately on crates.io, so I wonder if there's a bug in cargo-release's polling logic.
I'm Having the same problem but when releasing to a private repository.
The plug-in releases the crate correctly to my private registry (I have it defined in the Crate's Cargo.toml), but the plug-in checks crates.io Index (which is my default registry). It gets into a loop and never finishes.
Quick workaround for me is to specify registry as a parameter when releasing, then it pulls the correct index: cargo release rc -x --registry my-private-registry.
In our case, we don't use a private repo or a private registry.
Hm, this is the issue in my case:
[2022-03-25T14:44:04Z DEBUG git2::cred] executing credential helper "sh" "-c" "git credential-cache get"
[2022-03-25T14:44:04Z TRACE git2::cred] credential helper stderr ---
[2022-03-25T14:44:04Z TRACE git2::cred] ignoring output line:
[2022-03-25T14:44:04Z DEBUG cargo_release::cargo] Crate index update failed with failed to acquire username/password from local configuration
[2022-03-25T14:44:04Z INFO cargo_release::cargo] Waiting for publish to complete...
[2022-03-25T14:44:06Z DEBUG git2::cred] executing credential helper "sh" "-c" "git credential-cache get"
[2022-03-25T14:44:06Z TRACE git2::cred] credential helper stderr ---
[2022-03-25T14:44:06Z TRACE git2::cred] ignoring output line:
[2022-03-25T14:44:06Z DEBUG cargo_release::cargo] Crate index update failed with failed to acquire username/password from local configuration
[2022-03-25T14:44:08Z DEBUG git2::cred] executing credential helper "sh" "-c" "git credential-cache get"
[2022-03-25T14:44:08Z TRACE git2::cred] credential helper stderr ---
Moved to new issue #507
@jerusdp that is an unrelated problem to this thread. Please open another issue for the problem(s) you are concerned about
Just encountered this as well while using a private Cargo registry. The --registry my-private-registry trick by lpiepiora worked.
When this was originally opened
- We used the git index
- Our support for alternative registries was broken
Since then, we've switched to the sparse index and we bypass the blocking for alternative registries.
What would be helpful from people is
- Test with the latest version
- Report your version
- Report trace-level logs
Also, native support for waiting until the package has been published has been in cargo since 1.66. The question is at what point is it safe for us to remove our own waiting logic.
Without any further word on this, I'm assuming it is fixed