-
Notifications
You must be signed in to change notification settings - Fork 222
Description
I'm not sure about the best approach here. this is currently more or less a braindump of my current thoughts
about this.
The use-case is: crates wanting to validate their docs-build in their CI.
Currently we're recommending cargo docs-rs, which duplicates our custom metadata reading, generates a custom cargo command to check if the docs-build works.
current caveats:
- the command is not exactly the same, since the logic is duplicated, it might diverge more
- it's not using the docker build-image, so crates that need c-libraries need to install them themselves in the github workflow, and might diverge from our build-image.
- when your build script does network access, it will pass, while docs.rs fails.
- when your build script writes to the wrong folder, it will pass, while dosc.rs fails.
1) just reduce duplication
create & release a subcrate that just contains the cargo-command-creation and uses our metadata library. cargo-docs-rs can use it
2) do our own cargo docs-rs
build & release our own binary as subcrate, use whatever is needed from the codebase.
3) perfect world
build something that
- uses rustwide & docker
- uses
- and uses the correct command.
best case it's in a way that docs.rs itself is using the same component, and the new cargo docs-rs command would just use the same component.
Now, thinking about this: how far away is this from just running docs_rs_builder build crate ./local_path?