Re: [Xen-devel] [PATCH 2/3] Add a weekly coverity flight

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2016-02-03 at 12:12 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH 2/3] Add a weekly coverity flight"):
> > In my experiments the curl command took ~35 minutes to complete (rate
> > in the 100-200k range). Not sure if this is a problem. Note that curl
> > is run on the controller (via system_checked) and consequently has no
> > timeout etc.
> 
> Can you use curl's builtin timeouts, or wrap it in alarm() ?
> Otherwise I think it is possible for this to become wedged
> indefinitely and need manual un-wedging.

I added --max-time 3600.

> AFAICT during the curl the only lock or resource which is held is the
> build host share.ÂÂI think we can live with that.

There's the per-branch lock too, FWIW.

> > Deployment notes:
> > Â- Put cov-analysis-linux64-7.7.0.4.tar.gz in the Images
> > ÂÂÂdirectory. DONE in COLO
> > Â- Populate $HOME/.xen-osstest/coverity-secret with the token
> > ÂÂÂDONE in COLO
> > Â- Populate xen.git#coverity-scanned with an initial baseline, update
> > ÂÂÂap-fetch-version-old to refer to it instead of master.
> ...
> > +coverity)
> > +   #XXX doesn't exist yet, use master for now
> > repo_tree_rev_fetch_git xen $TREE_XEN coverity-scanned $LOCALREV_XEN
> 
> This XXX is out of date ?ÂÂAnd so the code should be fixed ?

coverity-scanned doesn't exist in xen.git yet, so for now this is still
correct, its the subject of the 3rd deployment note.

I'd be happy to pushÂ9937763265d9597e5f2439249b16d995842cdf0f (the subject
of my recent adhoc test) to that new branch in xen.git right away though if
you agree and then update this code.

> > +   case $branch in
> > +   ÂÂÂÂcoverity)
> > +           if [ "x$TREE_COVERITY" = x ]; then
> > +           ÂÂÂÂexport TREE_COVERITY=$TREE_XEN
> > +           fi
> > +           if [ "x$REVISION_COVERITY" = x ]; then
> > +           ÂÂÂÂdetermine_version REVISION_COVERITY coverity
> > COVERITY
> > +           ÂÂÂÂexport REVISION_COVERITY
> > +           fi
> > +           NEW_REVISION=$REVISION_COVERITY
> 
> I'm not sure why these variables are all REVISION_COVERITY rather than
> REVISION_XEN.

IIRC I had trouble getting cr-daily-branch's determine_version to populate
REVISION_XEN using values from "ap-fetch-version* coverity", maybe due to
the [ "x$tbranch" = "x$branch" ] ?Â

or else there was some other wrinkle around that area.

Ian.

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