Skip to content
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

Build failure not recorded if failure during crate fetch step #797

Closed
Nemo157 opened this issue Jun 1, 2020 · 5 comments
Closed

Build failure not recorded if failure during crate fetch step #797

Nemo157 opened this issue Jun 1, 2020 · 5 comments
Labels
A-builds Area: Building the documentation for a crate C-bug Category: This is a bug P-medium Medium priority

Comments

@Nemo157
Copy link
Member

Nemo157 commented Jun 1, 2020

If you run

> docker-compose run web build crate alcro 0.1.4

it will fail because of the lockfile (currently at least, this might be a bug). This is not recorded anywhere, so if it's built via the queue the version just silently disappears.

@jyn514
Copy link
Member

jyn514 commented Jul 19, 2020

Note that we still have a record of the crate: it's in the queue table with attempts set to 5. We just don't display that anywhere on the site - I think under the assumption this is an internal bug, but that's not always the case (#903).

@jyn514
Copy link
Member

jyn514 commented Jun 12, 2021

I think this can't be fixed without changes to rustwide. In particular, I don't think there's anything docs.rs can do without at least being able to parse the Cargo manifest, and we can't parse the manifest until we have access to the source directory:

let metadata = Metadata::from_crate_root(&build.host_source_dir())?;

And rustwide generates its own errors before ever running that closure :/ the error from alcro looks like

   5: rustwide::prepare::Prepare::fetch_deps::{{closure}}
             at /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/rustwide-0.13.0/src/prepare.rs:169
   6: core::result::Result<T,E>::map_err
             at /home/joshua/.local/lib/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/result.rs:591
   7: rustwide::prepare::Prepare::fetch_deps
             at /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/rustwide-0.13.0/src/prepare.rs:169
   8: rustwide::prepare::Prepare::fetch_deps
             at /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/rustwide-0.13.0/src/prepare.rs:166
   9: rustwide::prepare::Prepare::prepare
             at /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/rustwide-0.13.0/src/prepare.rs:44
  10: rustwide::build::BuildDirectory::run
             at /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/rustwide-0.13.0/src/build.rs:152
  11: rustwide::build::BuildBuilder::run
             at /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/rustwide-0.13.0/src/build.rs:89
  12: docs_rs::docbuilder::rustwide_builder::RustwideBuilder::build_package
             at src/docbuilder/rustwide_builder.rs:303

@jyn514
Copy link
Member

jyn514 commented Jun 12, 2021

I guess another thing we could do is just record the name and version? But at that point I think it makes more sense to fix #1011 instead, we don't have any more info available than what's in the index.

@Nemo157
Copy link
Member Author

Nemo157 commented Jun 12, 2021

Yep, my thoughts on this was definitely to do it after #1011, so that we can also create the build object in the database earlier to attach the log to, instead of only creating that after the end of the build process (also necessary for the ideas I had around #787 so we have something to attach all the other build logs to as the process happened).

@syphar
Copy link
Member

syphar commented Jun 23, 2024

solved with #2467

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-builds Area: Building the documentation for a crate C-bug Category: This is a bug P-medium Medium priority
Projects
None yet
Development

No branches or pull requests

3 participants