Re: [Xen-devel] [RFC OSSTEST] ap-fetch-*: Support $AP_FETCH_PLACEHOLDERS envvar which outputs a placeholder

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2015-10-08 at 17:00 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[RFC OSSTEST] ap-fetch-*: Support
> $AP_FETCH_PLACEHOLDERS envvar which outputs a placeholder"):
> > And use this in standalone-generate-dump-flight-runvars. In general I
> > don't think we are interested in the specific revision_* runvars when
> > using this tool and this is quicker even than using memoisation on the
> > ap-fetch invocations. This produces output like:
> > 
> > libvirt                    build-amd64                                 
> >        revision_xen            ap-fetch-version-baseline:xen-unstable
> > 
> > By doing this the diffs of before and after changes to e.g.
> > make-flight don't pickup noise if a something/someone does a push in
> > the middle.
> > 
> > RFC firstly because I'm not 100% sure about making this unconditional
> > in standalone-generate-dump-flight-runvars
> 
> Maybe it should be the default, but it is sometimes useful to see the
> effect of changes to ap-fetch* in the runvars.  Eg, my smoke test
> series would have needed not to be using these placeholders.

Right, I can easily (I hope) make that aspect work then.

> > and secondly because of the
> > addition of sqlite_use_immediate_transaction => 0 which TBH I don't
> > really understand but resolves errors like:
> 
> I can see why that helps but I don't think it's right.

I suspected as much.

> >     DBD::SQLite::db do failed: UNIQUE constraint failed: jobs.flight,
> > jobs.job [for Statement "        INSERT INTO jobs VALUES (?,'build-i386
> > -xsm','build','queued')
> 
> This is very odd.  These jobs ought to have been deleted by
> Osstest::JobDB::Standalone::flight_create.
> 
> This merits further investigation :-/.

Right :-/

Ian.

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