public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Baurzhan Ismagulov <ibr@radix50.net>
To: isar-users <isar-users@googlegroups.com>
Subject: Re: FYI: Feasibility of CI on github
Date: Fri, 12 Feb 2021 11:53:06 +0100	[thread overview]
Message-ID: <20210212105306.GG20742@yssyq.m.ilbers.de> (raw)
In-Reply-To: <20210212112840.70690286@md1za8fc.ad001.siemens.net>

On Fri, Feb 12, 2021 at 11:28:40AM +0100, Henning Schild wrote:
> Last time i checked avocado was not packaged properly

When we made our initial PoC with Avocado, we used their Debian packaging.
Unfortunately, it got broken with buster. I'll talk with upstream regarding
this.


> Plus the patches have been merged without a proper review

Your feedback happened to come after the merge; it has been addressed in our
patches to come. If you have further feedback, please share with us.


> There is something. Run many tests in parallel instead of all mc in
> one. The all mc has its place because we have mc, but maybe not the
> best choice for the default.

Ok, that is a viable option. We'd continue to test mc anyway, but maybe in a
separate, non-default job. I think we would still need to look at the problems
that we encountered with mc and define some minimal mc test case for the
default scenario.


> And one really important first step would be decoupling of CI and CT.

If CT = continuous testing, I've indeed handled that as one step in our
process; what could we decouple with which benefit?


> > What I don't understand is, after we have individual test cases, how
> > does that help us with the long run time? Would you schedule every
> > test case in different steps?
> 
> You get more control if you want to disable some aspects, you get
> better reporting, you can fail individual tasks without failing "in
> total". You do not need to "keep going" when something failed, or you
> can keep going if that is what you want ... more control.

Those are arguments for a test framework in general -- I agree, this is why
we've introduced Avocado in the first place. If I understood Jan correctly, his
point was to make the run time shorter -- this could rather be solved by a
shorter default testsuite. We would then run the full testsuite on better
hardware before merging. That said, we already have the shorter variant; maybe
we should switch it to be the default?


With kind regards,
Baurzhan.

  reply	other threads:[~2021-02-12 10:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-09 12:53 Jan Kiszka
2021-02-12  9:16 ` Henning Schild
2021-02-12 10:01   ` Baurzhan Ismagulov
2021-02-12 10:28     ` Henning Schild
2021-02-12 10:53       ` Baurzhan Ismagulov [this message]
2021-02-12 16:55         ` Jan Kiszka
2021-02-15 11:30           ` Baurzhan Ismagulov
2021-02-12 19:20         ` Henning Schild
2021-02-15 11:27           ` Baurzhan Ismagulov
2021-02-15 13:45             ` Jan Kiszka

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=20210212105306.GG20742@yssyq.m.ilbers.de \
    --to=ibr@radix50.net \
    --cc=isar-users@googlegroups.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox