public inbox for git-commits@fedoraproject.org
help / color / mirror / Atom feed
From: Jesus Checa Hidalgo <jchecahi@redhat.com>
To: git-commits@fedoraproject.org
Subject: [tests/rust] main: net_err_suggests_fetch_with_cli: Try to fix timeouts once again
Date: Wed, 24 Jun 2026 15:06:18 GMT [thread overview]
Message-ID: <178231357805.1.15594594927588060400.tests-rust-875db0af2d37@fedoraproject.org> (raw)
A new commit has been pushed.
Repo : tests/rust
Branch : main
Commit : 875db0af2d3768fc2d3649f1911479a85df2f6f6
Author : Jesus Checa Hidalgo <jchecahi@redhat.com>
Date : 2026-06-24T08:45:55+02:00
Stats : +24/-27 in 2 file(s)
URL : https://src.fedoraproject.org/tests/rust/c/875db0af2d3768fc2d3649f1911479a85df2f6f6?branch=main
Log:
net_err_suggests_fetch_with_cli: Try to fix timeouts once again
Do not rely on negative matches such as "cargo output does not
suggest using fetch_with_cli". Instead, verify that cargo actually
calls git fetch on the remote repo.
Use timeout to cover systems where git ignores the http timeout.
Increase test timeout to 15m
---
diff --git a/tests/Sanity/net_err_suggests_fetch_with_cli/main.fmf b/tests/Sanity/net_err_suggests_fetch_with_cli/main.fmf
index 0de32b5..8d6c70a 100644
--- a/tests/Sanity/net_err_suggests_fetch_with_cli/main.fmf
+++ b/tests/Sanity/net_err_suggests_fetch_with_cli/main.fmf
@@ -13,3 +13,4 @@ description: |
support libssh2 in RHEL/CentOS.
tier: 1
+duration: 15m
diff --git a/tests/Sanity/net_err_suggests_fetch_with_cli/runtest.sh b/tests/Sanity/net_err_suggests_fetch_with_cli/runtest.sh
index ba7ed8a..bca1cc5 100755
--- a/tests/Sanity/net_err_suggests_fetch_with_cli/runtest.sh
+++ b/tests/Sanity/net_err_suggests_fetch_with_cli/runtest.sh
@@ -2,20 +2,17 @@
# vim: dict+=/usr/share/beakerlib/dictionary.vim cpt=.,w,b,u,t,i,k
. /usr/share/beakerlib/beakerlib.sh || exit 1
-# For the test remote depenency, we use a TEST-NET-1 address (192.0.2.1) instead
-# "needs-proxy.invalid" like upstream, to deal with potential catch-all DNS
-# resolvers that redirect any invalid domain to loopback. These result in a
-# connection refused (OS error) for any invalid host, but we need a network
-# error for cargo to recommend using fetch-with-cli.SS
-# To achieve it we use a documented test IP with a very short timeout that
-# will simulate the same effect of unreachable host, causing cargo to suggest
-# using the git fetch option.
+# Use TEST-NET-1 address (192.0.2.1) instead of "needs-proxy.invalid" to avoid
+# corporate DNS resolvers that redirect invalid domains to loopback, which would
+# cause OS errors instead of network errors. Cargo only suggests git-fetch-with-cli
+# for network errors, not OS errors.
CRATE_NAME="foo"
CRATE_VER="0.0.0"
REMOTE_URL="https://192.0.2.1/git"
+# Generate Cargo.toml with a git dependency pointing to an unreachable URL
function generate_cargo_toml() {
local dest_dir=$1
cat >> "$dest_dir/Cargo.toml" <<EOF
@@ -30,22 +27,27 @@ foo = { git = "$REMOTE_URL" }
EOF
}
+# Generate .cargo/config.toml enabling git-fetch-with-cli
function generate_cargo_conffile() {
mkdir ".cargo"
cat >> .cargo/config.toml <<EOF
- [net]
- git-fetch-with-cli = true
+[net]
+git-fetch-with-cli = true
EOF
}
+# Verify that cargo invokes system git when git-fetch-with-cli is enabled.
+# Accepts exit codes 101 (cargo error) and 124 (timeout), as git may hang
+# on systems where it doesn't respect timeout configuration.
function test_git-fetch-with-cli() {
local cargo_cmd="$1"
local log_file
log_file=$(mktemp)
- rlRun "$cargo_cmd |& tee $log_file" 101
- rlAssertGrep "unable to update $REMOTE_URL" "$log_file" -i || cat "$log_file"
- rlAssertNotGrep "net.git-fetch-with-cli" "$log_file" || cat "$log_file"
+ rlRun "$cargo_cmd |& tee $log_file" "101, 124"
+ rlAssertGrep "Updating.*$REMOTE_URL" "$log_file" -E || cat "$log_file"
+ # Verify cargo executed git (not just suggested it)
+ rlAssertGrep "git fetch.*$REMOTE_URL" "$log_file" -E || cat "$log_file"
rm -f "$log_file"
}
@@ -59,29 +61,23 @@ rlJournalStart
rlRun "pushd $tmp"
rlRun "mkdir src && touch src/lib.rs"
rlRun "set -o pipefail"
- # Cargo will try to resolve an IP that will never reply back.
- # To make the test run faster, reduce the timeout to 1 second instead
- # the default 30s
+ # Reduce timeout for cargo's built-in HTTP client (used without git-fetch-with-cli)
rlRun "export HTTP_TIMEOUT=1"
rlPhaseEnd
rlPhaseStartTest
+ # Test 1: Verify cargo suggests git-fetch-with-cli on network errors
rlRun "cargo check -v |& tee output.log" 101
- # Ensure DNS was not able to resolve the remote
- rlAssertGrep 'spurious network error' output.log
- rlAssertGrep "unable to update $REMOTE_URL" output.log -i
- # Ensure cargo suggests using net.git-fetch-with-cli
+ rlAssertGrep "Unable to update $REMOTE_URL" output.log -i
rlAssertGrep "net.git-fetch-with-cli" output.log
- # Use git-fetch-with-cli via envvar.
- test_git-fetch-with-cli "CARGO_NET_GIT_FETCH_WITH_CLI=true cargo check -v"
+ # Test 2-4: Verify cargo uses system git when git-fetch-with-cli is enabled
+ # (via environment variable, CLI flag, and config file respectively)
+ test_git-fetch-with-cli "CARGO_NET_GIT_FETCH_WITH_CLI=true timeout 5 cargo check -v"
+ test_git-fetch-with-cli "timeout 5 cargo --config net.git-fetch-with-cli=true check -v"
- # With cli override
- test_git-fetch-with-cli "cargo --config net.git-fetch-with-cli=true check -v"
-
- # With config file
generate_cargo_conffile
- test_git-fetch-with-cli "cargo check -v"
+ test_git-fetch-with-cli "timeout 5 cargo check -v"
rlPhaseEnd
rlPhaseStartCleanup
reply other threads:[~2026-06-24 15:06 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=178231357805.1.15594594927588060400.tests-rust-875db0af2d37@fedoraproject.org \
--to=jchecahi@redhat.com \
--cc=git-commits@fedoraproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox