All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xenproject.org
Subject: Re: [OSSTEST PATCH 3/3] smoke tests: Consider osstest revision when reusing builds
Date: Fri, 9 Oct 2015 13:31:30 +0100	[thread overview]
Message-ID: <1444393890.1410.362.camel@citrix.com> (raw)
In-Reply-To: <1444391314-1895-3-git-send-email-ian.jackson@eu.citrix.com>

On Fri, 2015-10-09 at 12:48 +0100, Ian Jackson wrote:
> Build results done with one version of osstest are not necessarily
> reuseable with a different version of osstest.  For example, the suite
> may have changed.  The smoke tests try to reuse builds from
> xen-unstable but if osstest changes incompatibly, the smoke tests
> might repeatedly fail until a xen-unstable flight using the new
> osstest completes.
> 
> (This issue is a problem for bisection too but that's less critical
> and there is less of an easy answer.)

Probably a bad idea, but I wonder: would comparing the hostflags required
of the two build hosts take care of some of this?

e.g. some random job I just pulled up:

    share-build-wheezy-amd64,arch-amd64,suite-wheezy,purpose-build

This is a bit tenuous though, since really it is $r{$ident_suite} //
$c{DebianSuite} which matters.

> 
[...]
> 3. After a manual force push of an untested osstest, there no suitable

                                                            ^ are

> builds on either xen-unstable or osstest.  The first
> xen-unstable-smoke run will have to do all the builds.  However,
> subsequent xen-unstable-smoke runs can just pick up those builds.
> These same builds will be reused until a xen-unstable flight using the
> new osstest produces a passing build.

4. After a push from another tree whose gated output is used by xen
-unstable-smoke (e.g. the linux-X.Y for the default kernel revision) then
there will be no suitable builds in either the latest xen-unstable or
osstest (neither of which are likely to have seen the linux push and built
it before a smoke run occurs) in which case xen-unstable-smoke will do that
build and then subsequently reuse it until a xen-unstable or osstest flight
occurs which uses that Linux tree.

(is that worth mentioning? is it correct?)

> We honour an environemnt variable SMOKE_HARNESS_REV to override the

"environment"

> automatic determination of the desired test harness revision.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

Despite the above:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

  reply	other threads:[~2015-10-09 12:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-09 11:48 [OSSTEST PATCH 1/3] Move get_harness_rev to Osstest from Osstest::Executive Ian Jackson
2015-10-09 11:48 ` [OSSTEST PATCH 2/3] sg-check-tested: Honour multiple branches (comma-separated) Ian Jackson
2015-10-09 12:32   ` Ian Campbell
2015-10-09 11:48 ` [OSSTEST PATCH 3/3] smoke tests: Consider osstest revision when reusing builds Ian Jackson
2015-10-09 12:31   ` Ian Campbell [this message]
2015-10-09 13:22     ` Ian Jackson
2015-10-09 13:28       ` Ian Campbell
2015-10-09 12:31 ` [OSSTEST PATCH 1/3] Move get_harness_rev to Osstest from Osstest::Executive Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1444393890.1410.362.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.