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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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.

> 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.

>     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 :-/.

Ian.

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