t7900: fix host-dependent behaviour when testing git-maintenance(1)

We have recently added a new test to t7900 that exercises whether
git-maintenance(1) fails as expected when the "schedule.lock" file
exists. The test depends on whether or not the host has the required
executables present to schedule maintenance tasks in the first place,
like systemd or launchctl -- if not, the test fails with an unrelated
error before even checking for the lock file. This fails for example in
our CI systems, where macOS images do not have launchctl available.

Fix this issue by creating a stub systemctl(1) binary and using the
systemd scheduler.

Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Patrick Steinhardt
2024-11-25 06:33:41 +01:00
committed by Junio C Hamano
parent 656ca9204a
commit ba874d1dac

View File

@ -996,10 +996,15 @@ test_expect_success 'repacking loose objects is quiet' '
' '
test_expect_success 'maintenance aborts with existing lock file' ' test_expect_success 'maintenance aborts with existing lock file' '
test_when_finished "rm -rf repo" && test_when_finished "rm -rf repo script" &&
mkdir script &&
write_script script/systemctl <<-\EOF &&
true
EOF
git init repo && git init repo &&
: >repo/.git/objects/schedule.lock && : >repo/.git/objects/schedule.lock &&
test_must_fail git -C repo maintenance start 2>err && test_must_fail env PATH="$PWD/script:$PATH" git -C repo maintenance start --scheduler=systemd 2>err &&
test_grep "Another scheduled git-maintenance(1) process seems to be running" err test_grep "Another scheduled git-maintenance(1) process seems to be running" err
' '