On Tue, Mar 19, 2024 at 8:10 AM Max Gautier <mg@xxxxxxxxxxxxxxxx> 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.
