lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lilypond-auto] Patchy report from grenouille


From: David Kastrup
Subject: Re: [Lilypond-auto] Patchy report from grenouille
Date: Mon, 06 Aug 2012 10:48:24 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

John Mandereau <address@hidden> writes:

>> error: failed to push some refs to '/var/src/lilypond-git'
>
> This is normal and wpuld have happened even without the deletion of
> test-master-lock by the Patchy run at 16:55 UTC: Phil's Patchy picked up
> a revision in staging newer than when my Patchy started, and his run
> completed a lot earlier; in this case I think a message should say
> "Info: origin/staging has been fastforwarded to a newer revision than
> last fetch to the repository of this computer." and not CC
> lilypond-devel.

This should actually be more diverse.  Before pushing the new
test-staging, Patchy should redo git fetch.

It should then check that

git log -1 origin/staging..test-staging

has _empty_ output!!!!  If this is _not_ the case, some commits in
test-staging have been _removed_ from origin/staging.  We've had the
situation a lot in the past that I tried resetting origin/staging to
fight bad material getting into master, and then subsequently it was
still pushed by some already started Patchy.  If we have Patchy
instances that run for 8 hours, this problem is acerbated.  So Patchy
should really do a last-minute check that what is going to push is still
wanted.

If it is not empty, abort and send a mail with the message "staging has
been reset, aborting operation without pushing".

If that's empty, then we can check

git log -1 origin..test-staging

If this is empty, pushing will not achieve anything.  Just end without
sending a mail.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]