On 4/5/2020 11:41 AM, Phillip Wood wrote: > Hi Stolee > > On 03/04/2020 21:48, Derrick Stolee via GitGitGadget wrote: >> From: Derrick Stolee <dstolee@xxxxxxxxxxxxx> >> >> The 'git job-runner' command was introduced with a '--repo=<path>' >> option so a user could start a process with an explicit list of >> repos. However, it is more likely that we will want 'git >> job-runner' to start without any arguments and discover the set of >> repos from another source. > > One thought that occurred to me was that it might be convenient to put > 'git job-runner $HOME &' in my .bashrc to have it start on login and > find all the repositories under $HOME without me having to list each > one (and remember to update the list each time a clone a new repository). > There are a couple of issues with this > 1 - We only want to run the jobs once per repo, not for each worktree. > That should be easy enough to implement by checking if we're in the > main worktree. This idea of "please check all (immediate) directories under <dir> for repositories to run maintenance" is an interesting one. It certainly could be added later. Your concern about worktrees is actually not a big deal. Since we check the config for the "last run" of a job on a repo, we will not run the same job immediately on a worktree after running it on the original (unless the interval times are incredibly short). > 2 - If I start several shells I only want one instance of 'git > job-runner' to start. One way to handle that would be for the runner > to hold a lock file in the directory it's given and quit if the lock > is already taken. It should probably walk up the directory hierarchy > to check for lock files as well in case I try to start another > job-runner instance in a subdirectory. This is an interesting idea. My gut reaction is that we don't want to prevent users from running multiple processes if they want to. But if they run the process twice in the same directory then they are likely to be running on the same set of repos (barring "-c jobs.repo" or equivalent). Again, my hope is that we would solve this problem by having a cross- platform "job service" that makes the user setup of editing .bashrc irrelevant. Not only is that idea getting push back, we should allow expert users the ability to customize these steps to their delight. Thanks, -Stolee
