]> git.ipfire.org Git - thirdparty/git.git/commit - t/helper/test-tool.c
maintenance: add start/stop subcommands
authorDerrick Stolee <dstolee@microsoft.com>
Fri, 11 Sep 2020 17:49:18 +0000 (17:49 +0000)
committerJunio C Hamano <gitster@pobox.com>
Fri, 25 Sep 2020 17:59:44 +0000 (10:59 -0700)
commit2fec604f8df51fcf47551723e68a3447915b9eb9
tree7373599d9ca099967136d0082cf572a4e23d62a2
parent0c18b700810ab2e2a4fac0d5b54a817141198a27
maintenance: add start/stop subcommands

Add new subcommands to 'git maintenance' that start or stop background
maintenance using 'cron', when available. This integration is as simple
as I could make it, barring some implementation complications.

The schedule is laid out as follows:

  0 1-23 * * *   $cmd maintenance run --schedule=hourly
  0 0    * * 1-6 $cmd maintenance run --schedule=daily
  0 0    * * 0   $cmd maintenance run --schedule=weekly

where $cmd is a properly-qualified 'git for-each-repo' execution:

$cmd=$path/git --exec-path=$path for-each-repo --config=maintenance.repo

where $path points to the location of the Git executable running 'git
maintenance start'. This is critical for systems with multiple versions
of Git. Specifically, macOS has a system version at '/usr/bin/git' while
the version that users can install resides at '/usr/local/bin/git'
(symlinked to '/usr/local/libexec/git-core/git'). This will also use
your locally-built version if you build and run this in your development
environment without installing first.

This conditional schedule avoids having cron launch multiple 'git
for-each-repo' commands in parallel. Such parallel commands would likely
lead to the 'hourly' and 'daily' tasks competing over the object
database lock. This could lead to to some tasks never being run! Since
the --schedule=<frequency> argument will run all tasks with _at least_
the given frequency, the daily runs will also run the hourly tasks.
Similarly, the weekly runs will also run the daily and hourly tasks.

The GIT_TEST_CRONTAB environment variable is not intended for users to
edit, but instead as a way to mock the 'crontab [-l]' command. This
variable is set in test-lib.sh to avoid a future test from accidentally
running anything with the cron integration from modifying the user's
schedule. We use GIT_TEST_CRONTAB='test-tool crontab <file>' in our
tests to check how the schedule is modified in 'git maintenance
(start|stop)' commands.

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/git-maintenance.txt
Makefile
builtin/gc.c
t/helper/test-crontab.c [new file with mode: 0644]
t/helper/test-tool.c
t/helper/test-tool.h
t/t7900-maintenance.sh
t/test-lib.sh