In part 3 I described how to write targets which can access network resources, and how to use memoization to make them run fast. In this (last) part of the series, I’ll describe the final feature of goaljobs — periodic jobs.
If you wanted to use
make to monitor a git repository and do a build when a new commit appears there would I guess be three choices: You could just run the
make command manually over and over again. You could have a git hook that runs
make. Or you have a cron job the periodically checks the git repository.
The git hook is the ideal solution for goaljobs too, but goaljobs also has cron-like periodic jobs built in, and they are very easy to use:
every 30 minutes (fun () -> let commit = shout "cd %s && git rev-parse HEAD" repo in require (git_commit_tested commit) )
every 30 minutes is self-explanatory (right?). The function that runs every half-an-hour is two lines of code. The first line uses
shout to run a shell command and capture the output. In this case git prints the current commit. The second command requires that the
git_commit_tested goal is reached for this commit.
One way to implement this goal would be:
let goal git_commit_tested commit = let key = sprintf "repo-tested-%s" commit in target (memory_exists key); sh " git clone %s test cd test ./configure make make check " repo_url; memory_set key "1"
This code clones the repository and runs
make check to test it. It uses the Memory (ie. memoization) to ensure that the tests are run at most once per commit.
Actually this is not quite true: the tests run successfully once, but if the test fails, it will keep running every 30 minutes and nag you about it. It’s trivial to change the memoization to remember failures as well as successes, or you could consider the repeated nagging to be a feature not a bug …
That’s it! The goaljobs website will be this (I’ve not uploaded it yet, but will do in the next day or two):