Re: automated computing tasks for lilypond

[James]

John,

On 30 August 2012 08:08, John Mandereau <address@hidden> wrote:
> Il giorno mer, 29/08/2012 alle 22.52 +0100, James ha scritto:
>> OK I have set up all the push access and done a test and it seems to
>> work, I cannot yet get it to send the email.. hmm.. probably some
>> silly typo somewhere.
>
> Might a sample msmtp configuration file help?  IIRC I sent one to Phil,
> if it could be useful for you then I'll add it to the CG.

Yes actually that would help. Also what would be useful in a similar
vein would be what I need to configure where in my 'config' so that
when I do accept or reject patchy.py I don't have to keep adding my
user and password to the gmail account. We have two of config files.
lilypond-patchy-config and .msmtp-patchy (used by patchy staging).

> You could
> also send me your msmtp config file, privately and without the username
> and password, with hints on what your SMTP server expects
> (authentication method, TLS/SSL option...)

I can do that when I get home sure.

>
>
>> I'll run patchy manually when I get up in the morning (about 7 hours
>> from now-ish) and then will run it manually when I get back from work
>> tomorrow evening and hopefully have more time to work out the kinks
>> with this email business.
>
> Is the manual running of Patchy/staging twice a day the frequency you
> aim at in production phase too?

not especially, I could run it every hour if you wanted? It takes
about 20 minutes to do a full merge.

I used to run it every 6 hours, but because I didn't have any email
notifications to watch it from work, I was a bit hesitant to do so.

James

> Ideally it should run at least four
> times a day in the presence of new commits in staging, but even if you
> run it just twice a day this frees up to 7 hours of CPU time on
> Grenouille, which helps a lot; in such a setup, I've reenabled
> Patchy/staging on Grenouille to run at noonish and midnightish, which is
> good for updating the docs online, and in a near future providing the
> test baseline for subsequent patches test in case the build of staging
> results in a merge into master.