You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
kornelski opened this issue
Apr 21, 2024
· 3 comments
· Fixed by #2529
Labels
A-backendArea: Webserver backendA-buildsArea: Building the documentation for a crateC-bugCategory: This is a bugE-easyEffort: Should be easy to implement and would make a good first PR
I would expect the source view to show only files present in the crate tarball. It's concerning that this looks like a "dirty" state after cargo has been run.
The text was updated successfully, but these errors were encountered:
valid point, the file is likely a remainder from the build process, since currently we're copying the source after the builds.
The solution is of course to copy / upload the source before we build the crate, which will also neatly fit into #2467 as an intermediate result we can expose for failed builds.
syphar
added
E-easy
Effort: Should be easy to implement and would make a good first PR
A-builds
Area: Building the documentation for a crate
A-backend
Area: Webserver backend
C-bug
Category: This is a bug
labels
May 3, 2024
The displayed Cargo.lock is also updated, i.e. may contain newer versions than the lock file already present in the package. This just gave me a lot of confusion when trying to figure out why a cargo install --locked build was using versions older than docs.rs showed.
(I imagine that a malicious package could also change its own files during build to hide them from the source view.)
A-backendArea: Webserver backendA-buildsArea: Building the documentation for a crateC-bugCategory: This is a bugE-easyEffort: Should be easy to implement and would make a good first PR
For example, the source view for homestar-workspace-hack 0.1.0 shows it has a
Cargo.lock
file. However, the crate tarball (sha256 f8262aa8f1bd0abeb4d0cdf11ec0dcdfef10951df63a4b09741665c9bd7531b1) has no such file.I would expect the source view to show only files present in the crate tarball. It's concerning that this looks like a "dirty" state after
cargo
has been run.The text was updated successfully, but these errors were encountered: