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