Closed aevyrie closed 3 months ago
That shouldn't be the issue, we only build docs for the lib
target. This line makes me think cargo
doesn't believe the crate has a lib
target for some reason, but skimming the Cargo.toml
nothing stands out to me for why that would be:
warning: target filter specified, but no targets matched; this is a no-op
Ah wait no, there's more logs that have been stripped because they're too long, they start with:
process didn't exit successfully: `/opt/rustwide/rustup-home/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rustdoc --edition=2021 --crate-type lib --crate-name bevy_mod_picking src/lib.rs --target x86_64-unknown-linux-gnu -o /opt/rustwide/target/x86_64-unknown-linux-gnu/doc
and go on for pages and pages of repetitive --extern-html-root-url
s (https://github.com/rust-lang/cargo/issues/13543).
That is probably not the cause though, just hiding the ability to see the failure code. I wonder if it is an out of memory error, you could try time -v cargo rustdoc --lib --all-features
to see what the memory usage is like.
There is a self-referential dev-dependency
, maybe it's that? I'll try timing as well.
Command being timed: "cargo rustdoc --lib --all-features"
User time (seconds): 14.02
System time (seconds): 3.77
Percent of CPU this job got: 182%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:09.76
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 576832
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 7908
Minor (reclaiming a frame) page faults: 1038399
Voluntary context switches: 2187
Involuntary context switches: 71758
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 414
Socket messages received: 618
Signals delivered: 112
Page size (bytes): 16384
Exit status: 0
So, 576 MB if I'm reading this correctly. I'm on macos, so I had to install gtime
to get verbose output.
I've tried removing the self reference, which doesn't seem to be used, and republished.
That did not seem to change anything. https://docs.rs/crate/bevy_mod_picking/0.18.1/builds/1149464
short update: we still don't know the actual error
But we'll wait until cargo is fixed (next nightly or the one after) and try the build again.
Alternatively we see if we can get https://github.com/rust-lang/rustwide/pull/83 released & integrated into docs.rs, and then re-run the build.
Let me know if there is anything I can do locally to debug this. Thanks!
nightly-2024-03-08
should contain the Cargo fix https://github.com/rust-lang/cargo/pull/13544/commits/ac750a1e9fe5d341b757f7e0d14a718287e42254 Nemo157 mentioned.
thanks for the ping!
I queued a rebuild for bevy_mod_picking 0.18.1 : https://docs.rs/releases/queue
it looks like the build succeeded now: https://docs.rs/bevy_mod_picking/0.18.1/bevy_mod_picking/
I'm aware we still don't know what the actual build failure was, if it failed becauses of the huge amount of logs? or something else.
Thanks!
Crate name
bevy_mod_picking
Build failure link
https://docs.rs/crate/bevy_mod_picking/0.18.0/builds/1148272
Additional details
I think this latest release added an 11th build target, which is why it is now failing. Running
cargo doc --all-features --no-deps --workspace
locally generates 11 output files, which I assume is the issue. Unfortunately, the logs are truncated, so I'm just guessing at the issue.