whenjobs 0.7.0 released

I’ve just released whenjobs 0.7.0 to fix a couple of problems that I was having myself.

Firstly, while it’s a nice feature of whenjobs that I can set variables, sometimes I don’t want jobs to be triggered as a result of setting variables. The new whenjobs --whisper command lets me set variables without reevaluating when-clauses:

$ whenjobs --whisper libguestfs_version=1.17.16

Secondly, my jobs file was getting pretty long and unmaintainable (400 lines), since I added various libguestfs branches and hivex to be managed by whenjobs. So I’ve added a feature where you can split the jobs file into multiple files:

$ ls -l .whenjobs/*.ml
-rw-rw-r--. 1 rjones rjones 3284 Mar 13 19:10 .whenjobs/jobs_hivex.ml
-rw-rw-r--. 1 rjones rjones 4039 Mar 13 19:07 .whenjobs/jobs_libguestfs.ml
-rw-rw-r--. 1 rjones rjones 3766 Mar 13 19:09 .whenjobs/jobs_libguestfs_stable.ml
-rw-rw-r--. 1 rjones rjones   45 Mar 13 19:10 .whenjobs/jobs.ml

I think I described whenjobs as a “cron replacement”. It is a cron replacement for me, for my personal use, but it’s not officially a cron replacement and this project has nothing whatsoever to do with Red Hat or Fedora. The reason I say this is I get some pretty idiotic comments like these.

whenjobs 0.6 released

whenjobs 0.6 fixes two out of three bugs mentioned previously, and fixes the bug Joe found in whenjobs --daemon-start (et al).

Changes:

• You can set multiple variables atomically, using:

  whenjobs --set cat=sushi food=fish
  

  The effect is that when-clauses are reevaluated only after all the variables have changed, rather than after each change as before.

• You can test the effect of setting variables, without setting them (or running jobs). The new --test option displays which jobs would run:

  $ whenjobs --test food=meat
  job$1
  job$5
  

• whenjobs --daemon-{start,restart,status} now all work as expected
• whenjobs --job-names lists job names of all loaded jobs, whether running or not.

Joe ‘Zonker’ Brockmeier looks at whenjobs

https://www.linux.com/learn/tutorials/552976:weekend-project-take-a-look-at-cron-replacement-whenjobs

I’ve been using whenjobs quite a lot (probably I’m the single most extensive user). Some things I like:

• The ability to list jobs and ‘tail’ the output of jobs as they are running. A big improvement over cron where jobs are effectively opaque and undebuggable.
• Restarting jobs because of temporary failures.

And some things I don’t like:

• You can’t set multiple variables atomically.
• It’s hard to predict the effect of setting a variable, ie. which jobs will run after you execute a particular whenjobs --set command.
• It probably would be better if whenjobs could work across mulitple hosts, with each host having a shared view of the current variable state.

(The first two of these are fairly simple to fix)

Whenjobs now managing libguestfs development releases

I finally got whenjobs to entirely manage the libguestfs release process (still to do: stable branches, testing on anything except Fedora).

It is triggered by tagging a version in git, whereupon the script takes over, building a tarball, testing the tarball, pushing it to the website, and kicking off a build in Rawhide.

So far it’s been a success, to some degree. In hindsight I could probably have used incron, although that is far more ugly and would have been a real hack. Plain ol’ make might have worked too, although it would have required more babysitting.

More here including the script …

whenjobs — job lists, cancelling, algorithmic cleanup etc

You can now list and cancel jobs:

$ whenjobs --jobs
61 job$1
	running in: /tmp/whenjobs20d88a48f2c4eb0062e1b44ded6d0ae7
	started at: 2012-02-23 22:43:20
62 job$2
	running in: /tmp/whenjobse9e6b93c3ced1967cbf8c5865d6a1ccb
	started at: 2012-02-23 22:43:20
$ whenjobs --cancel 62

You can manually start jobs. Gerd’s ocamlnet makes it almost trivial to add new RPCs between the tool and the daemon, so adding functions like this is simple.

You can put arbitrary OCaml actions into the job script too, so you can run code when a job is cleaned up, and you will (soon) be able to create jobs algorithmically. For example, the standard mailto cleanup lets you send mail containing the output of the job when it finishes.

let from = "me@example.com"
let to_addr = "you@example.com"
let prefix = "hostname "
let script = << # shell script here >>

job (prefix ^ "poll")
cleanup (Whentools.mailto ~from to_addr)
every minute : script