[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/4] mips: Add more Avocado tests
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [PATCH 0/4] mips: Add more Avocado tests |
Date: |
Thu, 23 May 2019 18:30:32 -0300 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
On Thu, May 23, 2019 at 09:28:00AM -0400, Cleber Rosa wrote:
>
>
> ----- Original Message -----
> > From: "Philippe Mathieu-Daudé" <address@hidden>
> > To: "Eduardo Habkost" <address@hidden>, "Cleber Rosa" <address@hidden>
> > Cc: "Aleksandar Rikalo" <address@hidden>, "Philippe Mathieu-Daudé"
> > <address@hidden>, "Wainer dos Santos
> > Moschetta" <address@hidden>, address@hidden, "Aleksandar Markovic"
> > <address@hidden>,
> > "Aleksandar Markovic" <address@hidden>, "Aurelien Jarno" <address@hidden>
> > Sent: Thursday, May 23, 2019 5:38:34 AM
> > Subject: Re: [Qemu-devel] [PATCH 0/4] mips: Add more Avocado tests
> >
> > On 5/23/19 1:07 AM, Eduardo Habkost wrote:
> > > On Wed, May 22, 2019 at 05:46:06PM -0400, Cleber Rosa wrote:
> > >> ----- Original Message -----
> > >>> From: "Eduardo Habkost" <address@hidden>
> > >>> On Tue, May 21, 2019 at 01:19:06AM +0200, Philippe Mathieu-Daudé wrote:
> > >>>> Hi,
> > >>>>
> > >>>> It was a rainy week-end here, so I invested it to automatize some
> > >>>> of my MIPS tests.
> > >>>>
> > >>>> The BootLinuxSshTest is not Global warming friendly, it is not
> > >>>> meant to run on a CI system but rather on a workstation previous
> > >>>> to post a pull request.
> > >>>> It can surely be improved, but it is a good starting point.
> > >>>
> > >>> Until we actually have a mechanism to exclude the test case on
> > >>> travis-ci, I will remove patch 4/4 from the queue. Aleksandar,
> > >>> please don't merge patch 4/4 yet or it will break travis-ci.
> > >>>
> > >>> Cleber, Wainer, is it already possible to make "avocado run" skip
> > >>> tests tagged with "slow"?
> > >>>
> > >>
> > >> The mechanism exists, but we haven't tagged any test so far as slow.
> > >>
> > >> Should we define/document a criteria for a test to be slow? Given
> > >> that this is highly subjective, we have to think of:
> > >>
> > >> * Will we consider the average or maximum run time (the timeout
> > >> definition)?
> > >>
> > >> * For a single test, what is "slow"? Some rough numbers from Travis
> > >> CI[1] to help us with guidelines:
> > >> - boot_linux_console.py:BootLinuxConsole.test_x86_64_pc: PASS (6.04
> > >> s)
> > >> - boot_linux_console.py:BootLinuxConsole.test_arm_virt: PASS (2.91 s)
> > >> -
> > >>
> > >> linux_initrd.py:LinuxInitrd.test_with_2gib_file_should_work_with_linux_v4_16:
> > >> PASS (18.14 s)
> > >> - boot_linux.py:BootLinuxAarch64.test_virt: PASS (396.88 s)
> > >
> > > I don't think we need to overthink this. Whatever objective
> > > criteria we choose, I'm sure we'll have to adapt them later due
> > > to real world problems.
> > >
> > > e.g.: is 396 seconds too slow? I don't know, it depends: does it
> > > break Travis and other CI systems often because of timeouts? If
> > > yes, then we should probably tag it as slow.
> > >
> > > If having subjective criteria is really a problem (I don't think
> > > it is), then we can call the tag "skip_travis", and stop worrying
> > > about defining what exactly is "slow".
> >
> > I'd go with a simpler "tags:travis-ci" whitelisting any job expecting to
> > run smoothly there.
> >
>
> My concern is what becomes of "make check-acceptance". Should we introduce
> another target, say, "make check-acceptance-ci" or just change its meaning
> and reuse it?
What about "make check-acceptance TAG=travis-ci"?
>
> > Then we can add "slow" tests without having to worry about blacklisting
> > for Travis CI.
> > Also, Other CI can set different timeouts.
> >
> > I'd like maintainers to add as many tests as they want to upstream, so
> > these tests can eventually run by anyone, then each maintainer is free
> > to select which particular set he wants to run as default.
> >
>
> OK, so this matches the idea of carefully curating a set of tests for
> CI. WRT white or blacklisting, I favor the approach that requires the
> least effort from the developer to have its test enabled, so I'd go
> with blacklisting. I fear that simple tests will just sit on the repo
> without being properly exercised if we need to whitelist them.
>
I agree. I'd prefer the default case to be simple and not
require extra tags. (i.e. tests without any tags would be run in
Travis by default).
--
Eduardo
- Re: [Qemu-devel] [PATCH 0/4] mips: Add more Avocado tests, (continued)
- Re: [Qemu-devel] [PATCH 0/4] mips: Add more Avocado tests, Cleber Rosa, 2019/05/23
- Re: [Qemu-devel] [PATCH 0/4] mips: Add more Avocado tests, Aleksandar Markovic, 2019/05/23
- Re: [Qemu-devel] [PATCH 0/4] mips: Add more Avocado tests, Philippe Mathieu-Daudé, 2019/05/23
- Re: [Qemu-devel] [PATCH 0/4] mips: Add more Avocado tests, Aleksandar Markovic, 2019/05/23
- Re: [Qemu-devel] [PATCH 0/4] mips: Add more Avocado tests, Eduardo Habkost, 2019/05/24
- Re: [Qemu-devel] [PATCH 0/4] mips: Add more Avocado tests, Eduardo Habkost, 2019/05/22
- Re: [Qemu-devel] [PATCH 0/4] mips: Add more Avocado tests, Cleber Rosa, 2019/05/22
- Re: [Qemu-devel] [PATCH 0/4] mips: Add more Avocado tests, Eduardo Habkost, 2019/05/22
- Re: [Qemu-devel] [PATCH 0/4] mips: Add more Avocado tests, Philippe Mathieu-Daudé, 2019/05/23
- Re: [Qemu-devel] [PATCH 0/4] mips: Add more Avocado tests, Cleber Rosa, 2019/05/23
- Re: [Qemu-devel] [PATCH 0/4] mips: Add more Avocado tests,
Eduardo Habkost <=
- Re: [Qemu-devel] [PATCH 0/4] mips: Add more Avocado tests, Aleksandar Markovic, 2019/05/24
- Re: [Qemu-devel] [PATCH 0/4] mips: Add more Avocado tests, Eduardo Habkost, 2019/05/24