cargo/tests/testsuite/source_replacement.rs

296 lines
7.7 KiB
Rust
Raw Normal View History

//! Tests for `[source]` table (source replacement).
use std::fs;
use cargo_test_support::registry::{Package, RegistryBuilder, TestRegistry};
use cargo_test_support::{cargo_process, paths, project, t};
fn setup_replacement(config: &str) -> TestRegistry {
let crates_io = RegistryBuilder::new()
.no_configure_registry()
.http_api()
.build();
let root = paths::root();
t!(fs::create_dir(&root.join(".cargo")));
2024-01-26 19:40:46 +00:00
t!(fs::write(root.join(".cargo/config.toml"), config,));
crates_io
}
#[cargo_test]
fn crates_io_token_not_sent_to_replacement() {
// verifies that the crates.io token is not sent to a replacement registry during publish.
let crates_io = setup_replacement(
r#"
[source.crates-io]
replace-with = 'alternative'
"#,
);
let _alternative = RegistryBuilder::new()
.alternative()
.http_api()
.no_configure_token()
.build();
let p = project()
.file(
"Cargo.toml",
r#"
[package]
name = "foo"
version = "0.0.1"
authors = []
license = "MIT"
description = "foo"
"#,
)
.file("src/lib.rs", "")
.build();
p.cargo("publish --no-verify --registry crates-io")
.replace_crates_io(crates_io.index_url())
.with_stderr_contains("[UPDATING] crates.io index")
.run();
}
#[cargo_test]
fn token_sent_to_correct_registry() {
// verifies that the crates.io token is not sent to a replacement registry during yank.
let crates_io = setup_replacement(
r#"
[source.crates-io]
replace-with = 'alternative'
"#,
);
let _alternative = RegistryBuilder::new().alternative().http_api().build();
cargo_process("yank foo@0.0.1 --registry crates-io")
.replace_crates_io(crates_io.index_url())
.with_stderr(
"\
[UPDATING] crates.io index
[YANK] foo@0.0.1
",
)
.run();
cargo_process("yank foo@0.0.1 --registry alternative")
.replace_crates_io(crates_io.index_url())
.with_stderr(
"\
[UPDATING] `alternative` index
[YANK] foo@0.0.1
",
)
.run();
}
#[cargo_test]
fn ambiguous_registry() {
// verifies that an error is issued when a source-replacement is configured
// and no --registry argument is given.
let crates_io = setup_replacement(
r#"
[source.crates-io]
replace-with = 'alternative'
"#,
);
let _alternative = RegistryBuilder::new()
.alternative()
.http_api()
.no_configure_token()
.build();
cargo_process("yank foo@0.0.1")
.replace_crates_io(crates_io.index_url())
.with_status(101)
.with_stderr(
"\
error: crates-io is replaced with remote registry alternative;
include `--registry alternative` or `--registry crates-io`
",
)
.run();
}
#[cargo_test]
fn yank_with_default_crates_io() {
// verifies that no error is given when registry.default is used.
let crates_io = setup_replacement(
r#"
[source.crates-io]
replace-with = 'alternative'
[registry]
default = 'crates-io'
"#,
);
let _alternative = RegistryBuilder::new().alternative().http_api().build();
cargo_process("yank foo@0.0.1")
.replace_crates_io(crates_io.index_url())
.with_stderr(
"\
[UPDATING] crates.io index
[YANK] foo@0.0.1
",
)
.run();
}
#[cargo_test]
fn yank_with_default_alternative() {
// verifies that no error is given when registry.default is an alt registry.
let crates_io = setup_replacement(
r#"
[source.crates-io]
replace-with = 'alternative'
[registry]
default = 'alternative'
"#,
);
let _alternative = RegistryBuilder::new().alternative().http_api().build();
cargo_process("yank foo@0.0.1")
.replace_crates_io(crates_io.index_url())
.with_stderr(
"\
[UPDATING] `alternative` index
[YANK] foo@0.0.1
",
)
.run();
}
#[cargo_test]
fn publish_with_replacement() {
// verifies that the crates.io token is not sent to a replacement registry during publish.
let crates_io = setup_replacement(
r#"
[source.crates-io]
replace-with = 'alternative'
"#,
);
let _alternative = RegistryBuilder::new()
.alternative()
.http_api()
.no_configure_token()
.build();
// Publish bar only to alternative. This tests that the publish verification build
// does uses the source replacement.
Package::new("bar", "1.0.0").alternative(true).publish();
let p = project()
.file(
"Cargo.toml",
r#"
[package]
name = "foo"
version = "0.0.1"
authors = []
license = "MIT"
description = "foo"
[dependencies]
bar = "1.0"
"#,
)
.file("src/lib.rs", "")
.build();
// Verifies that the crates.io index is used to find the publishing endpoint
// and that the crate is sent to crates.io. The source replacement is only used
// for the verification step.
p.cargo("publish --registry crates-io")
.replace_crates_io(crates_io.index_url())
.with_stderr(
fix(publish): Block until it is in index Originally, crates.io would block on publish requests until the publish was complete, giving `cargo publish` this behavior by extension. When crates.io switched to asynchronous publishing, this intermittently broke people's workflows when publishing multiple crates. I say interittent because it usually works until it doesn't and it is unclear why to the end user because it will be published by the time they check. In the end, callers tend to either put in timeouts (and pray), poll the server's API, or use `crates-index` crate to poll the index. This isn't sufficient because - For any new interested party, this is a pit of failure they'll fall into - crates-index has re-implemented index support incorrectly in the past, currently doesn't handle auth, doesn't support `git-cli`, etc. - None of these previous options work if we were to implement workspace-publish support (#1169) - The new sparse registry might increase the publish times, making the delay easier to hit manually - The new sparse registry goes through CDNs so checking the server's API might not be sufficient - Once the sparse registry is available, crates-index users will find out when the package is ready in git but it might not be ready through the sparse registry because of CDNs So now `cargo` will block until it sees the package in the index. - This is checking via the index instead of server APIs in case there are propagation delays. This has the side effect of being noisy because of all of the "Updating index" messages. - This is done unconditionally because cargo used to block and that didn't seem to be a problem, blocking by default is the less error prone case, and there doesn't seem to be enough justification for a "don't block" flag. The timeout was 5min but I dropped it to 1m. Unfortunately, I don't have data from `cargo-release` to know what a reasonable timeout is, so going ahead and dropping to 60s and assuming anything more is an outage. Fixes #9507
2022-07-21 16:48:29 +00:00
"\
[UPDATING] crates.io index
[WARNING] manifest has no documentation, homepage or repository.
See https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata for more info.
[PACKAGING] foo v0.0.1 ([..])
[VERIFYING] foo v0.0.1 ([..])
[UPDATING] `alternative` index
[DOWNLOADING] crates ...
[DOWNLOADED] bar v1.0.0 (registry `alternative`)
[COMPILING] bar v1.0.0
[COMPILING] foo v0.0.1 ([..]foo-0.0.1)
[FINISHED] dev [..]
[PACKAGED] [..]
fix(publish): Block until it is in index Originally, crates.io would block on publish requests until the publish was complete, giving `cargo publish` this behavior by extension. When crates.io switched to asynchronous publishing, this intermittently broke people's workflows when publishing multiple crates. I say interittent because it usually works until it doesn't and it is unclear why to the end user because it will be published by the time they check. In the end, callers tend to either put in timeouts (and pray), poll the server's API, or use `crates-index` crate to poll the index. This isn't sufficient because - For any new interested party, this is a pit of failure they'll fall into - crates-index has re-implemented index support incorrectly in the past, currently doesn't handle auth, doesn't support `git-cli`, etc. - None of these previous options work if we were to implement workspace-publish support (#1169) - The new sparse registry might increase the publish times, making the delay easier to hit manually - The new sparse registry goes through CDNs so checking the server's API might not be sufficient - Once the sparse registry is available, crates-index users will find out when the package is ready in git but it might not be ready through the sparse registry because of CDNs So now `cargo` will block until it sees the package in the index. - This is checking via the index instead of server APIs in case there are propagation delays. This has the side effect of being noisy because of all of the "Updating index" messages. - This is done unconditionally because cargo used to block and that didn't seem to be a problem, blocking by default is the less error prone case, and there doesn't seem to be enough justification for a "don't block" flag. The timeout was 5min but I dropped it to 1m. Unfortunately, I don't have data from `cargo-release` to know what a reasonable timeout is, so going ahead and dropping to 60s and assuming anything more is an outage. Fixes #9507
2022-07-21 16:48:29 +00:00
[UPLOADING] foo v0.0.1 ([..])
[UPLOADED] foo v0.0.1 to registry `crates-io`
note: Waiting for `foo v0.0.1` to be available at registry `crates-io`.
You may press ctrl-c to skip waiting; the crate should be available shortly.
[PUBLISHED] foo v0.0.1 at registry `crates-io`
fix(publish): Block until it is in index Originally, crates.io would block on publish requests until the publish was complete, giving `cargo publish` this behavior by extension. When crates.io switched to asynchronous publishing, this intermittently broke people's workflows when publishing multiple crates. I say interittent because it usually works until it doesn't and it is unclear why to the end user because it will be published by the time they check. In the end, callers tend to either put in timeouts (and pray), poll the server's API, or use `crates-index` crate to poll the index. This isn't sufficient because - For any new interested party, this is a pit of failure they'll fall into - crates-index has re-implemented index support incorrectly in the past, currently doesn't handle auth, doesn't support `git-cli`, etc. - None of these previous options work if we were to implement workspace-publish support (#1169) - The new sparse registry might increase the publish times, making the delay easier to hit manually - The new sparse registry goes through CDNs so checking the server's API might not be sufficient - Once the sparse registry is available, crates-index users will find out when the package is ready in git but it might not be ready through the sparse registry because of CDNs So now `cargo` will block until it sees the package in the index. - This is checking via the index instead of server APIs in case there are propagation delays. This has the side effect of being noisy because of all of the "Updating index" messages. - This is done unconditionally because cargo used to block and that didn't seem to be a problem, blocking by default is the less error prone case, and there doesn't seem to be enough justification for a "don't block" flag. The timeout was 5min but I dropped it to 1m. Unfortunately, I don't have data from `cargo-release` to know what a reasonable timeout is, so going ahead and dropping to 60s and assuming anything more is an outage. Fixes #9507
2022-07-21 16:48:29 +00:00
",
)
.run();
}
#[cargo_test]
fn undefined_default() {
// verifies that no error is given when registry.default is used.
let crates_io = setup_replacement(
r#"
[registry]
default = 'undefined'
"#,
);
cargo_process("yank foo@0.0.1")
.replace_crates_io(crates_io.index_url())
.with_status(101)
.with_stderr(
"[ERROR] registry index was not found in any configuration: `undefined`
",
)
.run();
}
#[cargo_test]
fn source_replacement_with_registry_url() {
let alternative = RegistryBuilder::new().alternative().http_api().build();
Package::new("bar", "0.0.1").alternative(true).publish();
let crates_io = setup_replacement(&format!(
r#"
[source.crates-io]
replace-with = 'using-registry-url'
[source.using-registry-url]
registry = '{}'
"#,
alternative.index_url()
));
let p = project()
.file(
"Cargo.toml",
r#"
[package]
name = "foo"
version = "0.0.1"
[dependencies.bar]
version = "0.0.1"
"#,
)
.file("src/lib.rs", "")
.build();
p.cargo("check")
.replace_crates_io(crates_io.index_url())
.with_stderr(
"\
[UPDATING] `using-registry-url` index
[DOWNLOADING] crates ...
[DOWNLOADED] bar v0.0.1 (registry `using-registry-url`)
[CHECKING] bar v0.0.1
[CHECKING] foo v0.0.1 ([CWD])
[FINISHED] dev [..]
",
)
.run();
}