Re: [RFC PATCH 3/5] maintenance: use packaged systemd units

[Eric Sunshine <sunshine@sunshineco.com>]

On Tue, Mar 19, 2024 at 8:10 AM Max Gautier <mg@max.gautier.name> wrote:
> I'm working on updating the test in t7900-maintenance.sh, but I might be
> missing something here:
>
> >test_expect_success 'start and stop Linux/systemd maintenance' '
> >   write_script print-args <<-\EOF &&
> >   printf "%s\n" "$*" >>args
> >   EOF
> >
> >   XDG_CONFIG_HOME="$PWD" &&
> >   export XDG_CONFIG_HOME &&
> >   rm -f args &&
> >   GIT_TEST_MAINT_SCHEDULER="systemctl:./print-args" git maintenance start --scheduler=systemd-timer &&
>
> Do I understand correctly that this means we're not actually running
> systemctl here, just printing the arguments to our file ?

That's correct. The purpose of GIT_TEST_MAINT_SCHEDULER is twofold.

The primary purpose is to test as much as possible without actually
mucking with the user's real scheduler-related configuration (whether
it be systemd, cron, launchctl, etc.). This means that we want to
verify that the expected files are created or removed by
git-maintenance, that they are well-formed, and that git-maintenance
is invoking the correct platform-specific scheduler-related command
with correct arguments (without actually invoking that command and
messing up the user's personal configuration).

The secondary purpose is to allow these otherwise platform-specific
tests to run on any platform. This is possible since, as noted above,
we're not actually running the platform-specific scheduler-related
command, but instead only capturing the command and arguments that
would have been applied had git-maintenace been run "for real" outside
of the test framework.

> >       for schedule in hourly daily weekly
> >       do
> >               test_path_is_missing "systemd/user/git-maintenance@$schedule.timer" || return 1
> >       done &&
> >       test_path_is_missing "systemd/user/git-maintenance@.service" &&
> >
> >       printf -- "--user disable --now git-maintenance@%s.timer\n" hourly daily weekly >expect &&
> >       test_cmp expect args
>
> The rest of the systemd tests only check that the service file are in
> XDG_CONFIG_HOME, which should not be the case anymore.
>
> However, the test does not actually check we have enabled and started
> the timers as it is , right ?

Correct. As noted above, we don't want to muck with the user's real
configuration, and we certainly don't want the system-specific
scheduler to actually kick off some command we're testing in the
user's account while the test script is running.

> Should I add that ? I'm not sure how, because it does not seem like the
> tests run in a isolated env, so it would mess with the systemd user
> manager of the developper running the tests...

No you don't want to add that since, as you state and as stated above,
it would muck with the user's own configuration which would be
undesirable.

> Regarding systemd-analyze verify, do the tests have access to the source
> directory in a special way, or is using '../..' enough ?

You can't assume that the source directory is available at "../.."
since the --root option (see t/README) allows the root of the tests
working-tree to reside outside of the project directory.

You may be able to use "$TEST_DIRECTORY/.." to reference files in the
source tree, though the documentation in t/test-lib.sh doesn't seem to
state explicitly that this is intended or supported use. However, a
few existing tests (t1021, t3000, t4023) already access files in the
source tree in this fashion, so there is precedent.