[PATCH] t/t7704-repack-cruft.sh: avoid failures during long-running tests

[PATCH] t/t7704-repack-cruft.sh: avoid failures during long-running tests

[Taylor Blau]

On systems where running t7704.09 takes longer than 10 seconds, the test
can fail.

The test works by doing the following:

  - First write three unreachable objects, backdating the mtime for a
    single object ($foo) which we expect to prune.

  - Repack the repository into a pack containing reachable objects, and
    another three cruft packs, each containing one of the objects
    written in the previous step.

  - Backdate the mtimes of the cruft pack *.mtimes files themselves.
    (Note that this does not affect what is pruned further down in the
    test, but is done to ensure that the cruft packs are rewritten
    during that step).

  - Then repack with --cruft-expiration=10.seconds.ago, expecting to
    prune one of the three unreachable objects written in the first
    step.

  - Assert that the surviving cruft packs were rewritten, object $foo is
    pruned, and unreachable objects $bar, and $baz remain in the
    repository.

If longer than 10 seconds pass between writing the three unreachable
objects (the first step) and the "git repack --cruft" (the fourth step),
we will mistakenly prune more objects than expected, causing the test to
fail.

The $foo object which we expect to prune has its mtime set back to
10,000 seconds relative to the current time, but we prune it with a
cutoff of 10.seconds.ago.

Instead, set the cutoff to be 1,000 seconds to give the test much longer
time to run without failing. This helps platforms where running
individual tests can perform slowly, on my machine this test runs much
more quickly:

    $ hyperfine './t7704-repack-cruft.sh --run=9'
    Benchmark 1: ./t7704-repack-cruft.sh --run=9
      Time (mean ± σ):     647.4 ms ±  30.7 ms    [User: 528.5 ms, System: 124.1 ms]
      Range (min … max):   594.1 ms … 696.5 ms    10 runs

Reported-by: Randall Becker <randall.becker@nexbridge.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
---
 t/t7704-repack-cruft.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t7704-repack-cruft.sh b/t/t7704-repack-cruft.sh
index 71e1ef3a10..959e6e2648 100755
--- a/t/t7704-repack-cruft.sh
+++ b/t/t7704-repack-cruft.sh
@@ -330,7 +330,7 @@ test_expect_success '--max-cruft-size with pruning' '
 		# repack (and prune) with a --max-cruft-size to ensure
 		# that we appropriately split the resulting set of packs
 		git repack -d --cruft --max-cruft-size=1M \
-			--cruft-expiration=10.seconds.ago &&
+			--cruft-expiration=1000.seconds.ago &&
 		ls $packdir/pack-*.mtimes | sort >cruft.after &&
 
 		for cruft in $(cat cruft.after)

base-commit: 406f326d271e0bacecdb00425422c5fa3f314930
-- 
2.46.0.46.g406f326d27.dirty

RE: [PATCH] t/t7704-repack-cruft.sh: avoid failures during long-running tests

[rsbecker]

On Monday, August 5, 2024 3:37 PM, Taylor Blau wrote:
>On systems where running t7704.09 takes longer than 10 seconds, the test can fail.
>
>The test works by doing the following:
>
>  - First write three unreachable objects, backdating the mtime for a
>    single object ($foo) which we expect to prune.
>
>  - Repack the repository into a pack containing reachable objects, and
>    another three cruft packs, each containing one of the objects
>    written in the previous step.
>
>  - Backdate the mtimes of the cruft pack *.mtimes files themselves.
>    (Note that this does not affect what is pruned further down in the
>    test, but is done to ensure that the cruft packs are rewritten
>    during that step).
>
>  - Then repack with --cruft-expiration=10.seconds.ago, expecting to
>    prune one of the three unreachable objects written in the first
>    step.
>
>  - Assert that the surviving cruft packs were rewritten, object $foo is
>    pruned, and unreachable objects $bar, and $baz remain in the
>    repository.
>
>If longer than 10 seconds pass between writing the three unreachable objects (the
>first step) and the "git repack --cruft" (the fourth step), we will mistakenly prune
>more objects than expected, causing the test to fail.
>
>The $foo object which we expect to prune has its mtime set back to
>10,000 seconds relative to the current time, but we prune it with a cutoff of
>10.seconds.ago.
>
>Instead, set the cutoff to be 1,000 seconds to give the test much longer time to run
>without failing. This helps platforms where running individual tests can perform
>slowly, on my machine this test runs much more quickly:
>
>    $ hyperfine './t7704-repack-cruft.sh --run=9'
>    Benchmark 1: ./t7704-repack-cruft.sh --run=9
>      Time (mean ± σ):     647.4 ms ±  30.7 ms    [User: 528.5 ms, System: 124.1 ms]
>      Range (min … max):   594.1 ms … 696.5 ms    10 runs
>
>Reported-by: Randall Becker <randall.becker@nexbridge.com>
>Signed-off-by: Taylor Blau <me@ttaylorr.com>
>---
> t/t7704-repack-cruft.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/t/t7704-repack-cruft.sh b/t/t7704-repack-cruft.sh index
>71e1ef3a10..959e6e2648 100755
>--- a/t/t7704-repack-cruft.sh
>+++ b/t/t7704-repack-cruft.sh
>@@ -330,7 +330,7 @@ test_expect_success '--max-cruft-size with pruning' '
> 		# repack (and prune) with a --max-cruft-size to ensure
> 		# that we appropriately split the resulting set of packs
> 		git repack -d --cruft --max-cruft-size=1M \
>-			--cruft-expiration=10.seconds.ago &&
>+			--cruft-expiration=1000.seconds.ago &&
> 		ls $packdir/pack-*.mtimes | sort >cruft.after &&
>
> 		for cruft in $(cat cruft.after)
>
>base-commit: 406f326d271e0bacecdb00425422c5fa3f314930
>--
>2.46.0.46.g406f326d27.dirty

LGTM. Thank you.