Le 19 mars 2024 18:17:27 GMT+01:00, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> a écrit : >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. Ok thanks, now I see why it's done this way. > >> > 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. > That makes things easier then :) >> 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. I'll look into those. Thanks for all the info ! -- Max Gautier
