Re: [Xen-devel] [PATCH v6 19/20] osstest: save/retrieve the last successfully tested FreeBSD build

[Roger Pau Monne <roger.pau@xxxxxxxxxx>]

On Tue, Jul 25, 2017 at 11:24:45AM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("Re: [PATCH v6 19/20] osstest: save/retrieve the last 
> successfully tested FreeBSD build"):
> > On Mon, Jul 24, 2017 at 04:56:25PM +0100, Ian Jackson wrote:
> > > Also I would like you to discuss explicitly (in a comment or commit
> > > message) about whether push or anoint should come first.  If push
> > > comes first then we can end up pushed but not anointed; and, vice
> > > versa.  What are the recovery arrangements from such a failure ?
> > 
> > Hm, that's a hard one. I think push should be our primary goal, and as
> > such we should try to do the push first, so that a failed anoint
> > doesn't prevent a push.
> > 
> > OTOH, doing a push and failing on anoint doesn't seem that critical,
> > osstest can still use the oldish anointed artifacts and continue
> > working, hoping that on the next pass the anoint will succeed.
> 
> But there might not be a next pass.  When we push, we overwrite the
> state information that triggered the run.  So we push first, and the
> anoint fails, then we end up in a state where if the input branch
> doesn't change, osstest won't run a new flight.
> 
> Conversely, if we anoint first: if a flight is anointed, but the
> corresponding revision is not pushed, then osstest ought to rerun the
> flight and do a further anoint (and hopefully a push).  But this does
> mean that osstest might anoint a series of identical outputs,
> defeating the point of keeping a few older versions.
> 
> A third option would be to push first, but to call mg-anoint and/or
> sg-check-tested to figure out whether the pushed revision was anointed
> and run the flight unconditionally if not.  An advantage of this is
> that if osstest is modified to add an architecture, this check would
> automatically fail and a flight would be run to generate the first
> "proper" anointed build from the (presumably preseeded by hand) ad-hoc
> anointed build.

OK, forcing a new flight if the anointed revision doesn't match
OLD_REVISION (regardless of whether OLD_REVISION == NEW_REVISION)
seems like the best option.

I don't think I have any other questions before I send a new version,
would you be fine with me sending only patches [17, 19]?

Also, could you please Ack/NAck patch 10? (it's trivial).

I would still push the whole lot with the updated tags to my repo, but
there's no need to spam the list with the whole series anymore at this
point IMHO.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel