Fetch a crate from each forge for real - #53
Merged
Merged
Conversation
#21 asserted the archive URLs while the package parses, which catches a wrong scheme but says nothing about whether the bytes arrive, extract to the layout rust_repo expects, and compile. Three fetches, one per scheme: codeberg forgejo, github's /archive/ scheme, built and tested gitlab.com /-/archive/<rev>/<name>-<rev>, built and tested salsa.debian.org gitlab on a host whose name does not say so, which is the case inference cannot get right. Download only: the crate behind it is a binary with a dependency graph this has no use for. These reach three third-party hosts during a test run. CI already fetches crates.io for every declaration, so the network is not a new dependency, but codeberg or salsa being down now fails a build here. No hashes are pinned. A forge archive is not guaranteed byte-stable, gzip settings have changed under people before, and a hash that breaks on its own is worse here than no hash on a crate nothing ships.
test/forge_fetch declares its own rust_resolve, and the root rust_project did not name it, so both crates it declares were in no lock and their imports resolved to nothing in the editor. CI caught this rather than a person: the guard added in #20 fails the build when a dep falls outside every lock, which is exactly what this was. It was working within two changes of being written.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #21, which is merged. That PR asserted the archive URLs at parse time. This checks the bytes arrive and compile.
What runs now
/archive/<rev>.tar.gz/-/archive/<rev>/<name>-<rev>.tar.gzgit_forge = "gitlab"name = "debcargo"asserted inside itThe third is the case inference cannot get right, and the only one that exercises the override. It is download-only on purpose:
debcargois a binary with a dependency graph this test has no use for, and 188KB of archive is enough to prove the URL reaches real bytes.Two things worth a decision
This puts three third-party hosts in the CI path. CI already fetches crates.io for every declaration, so the network is not a new dependency, but codeberg or salsa being down now fails a build here. If that is not wanted, these belong behind a label that CI can exclude, or in rust-corpus instead.
No hashes are pinned. A forge archive is not guaranteed byte-stable; gzip settings have changed under people before, and GitHub regenerated archives in 2023 breaking checksums across the ecosystem. A pinned hash gives integrity and can break on its own. For a crate nothing ships, no hash seemed the better trade, but a consumer pinning a fork should know the risk either way. Worth documenting, and worth its own issue if you want the rules to say something about it.
191 tests pass.