[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#36430: mcron would benefit from a better way to test jobs
From: |
Robert Vollmert |
Subject: |
bug#36430: mcron would benefit from a better way to test jobs |
Date: |
Mon, 8 Jul 2019 09:18:32 +0200 |
> On 7. Jul 2019, at 16:24, Ludovic Courtès <address@hidden> wrote:
>
> Hi Robert,
>
> Robert Vollmert <address@hidden> skribis:
>
>> Defined a mcron job in config.scm scheduled to run once a day,
>> with a scheme expression. How do I test this?
>>
>> herd schedule mcron lists the job as merely a “Lambda expression”.
>> I learned how to give it a descriptive name, but still there’s
>> no script linked that I can run by hand.
>
> Commit 89fdd9ee0cc8817283449b33a8c1a2604c575c7e changes the rottlog job
> in a simple way so we see an actual command rather than “Lambda
> expression”. I would recommend using this style to improve
> transparency.
I understand that passing an executable works better. But that also
loses the feature of allowing to write a script in place advertised by
the lambda variant.
I find that kind of “feature that doesn’t actually work” to be quite
painful.
A way to get the best of both worlds (within guix) would be to use
program-file / gexp, so maybe that’s what should be advertised in the
guix manual?
>> One major improvement would be to have:
>>
>> 1. `herd schedule mcron` lists jobs with some kind of id
>> 2. `herd execute mcron <id>` runs the specific mcron job
>>
>> Or perhaps, any mcron job could be turned into a simple argument-less
>> guile or shell script that’s shown in the schedule listing?
>
> The commit I’m referring to above does exactly that.
>
> Perhaps as a first step we could recommend this style more prominently
> in the manual?
I’ll see if I can get the gexp variant to work, and would provide
a manual patch if successful.
> Further improvements should probably go into mcron itself. It’s a
> rather small and simple code base, so if you were looking for a
> rewarding hacking session for the week-end, it’s probably a good
> candidate. ;-)
At this stage, there’s just too many small hacking sessions required
all over the place :). I’ll stick with filing bug reports for the
clear pain points if that’s ok?
Robert