All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org, Doug Goldstein <cardoe@cardoe.com>
Subject: Re: [PATCH 2/2] automation: add a smoke test for xen.efi on X86
Date: Thu, 3 Oct 2024 02:24:51 +0200	[thread overview]
Message-ID: <Zv3kVEljCcM-Ww91@mail-itl> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2410021618540.1138574@ubuntu-linux-20-04-desktop>

[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]

On Wed, Oct 02, 2024 at 04:30:25PM -0700, Stefano Stabellini wrote:
> On Thu, 3 Oct 2024, Marek Marczykowski-Górecki wrote:
> > The problem is this doesn't work. The group-level variable overrides the
> > one in yaml. See the commit message and the link there...
> 
> Now I understand the problem, well spotted, thanks!
> 
> The idea behind having TEST_TIMEOUT defined as a project CI/CD variable
> is that it depends on the test infrastructure rather than the Xen code.
> So if we suddenly had slower runners we could change TEST_TIMEOUT
> without having to change the Xen code itself. So I think we should keep
> TEST_TIMEOUT as a project CI/CD variable.
> 
> I am not a fan of overwriting the TEST_TIMEOUT variable in the test
> scripts, because one test script can be used for multiple different
> tests, possibly even with different runners. For instance
> qubes-x86-64.sh works with a couple of different hardware runners that
> could have different timeout values. But I think it would work OK for
> now for our hardware-based tests (e.g. xilinx-smoke-dom0less-arm64.sh
> and qubes-x86-64.sh could overwrite TEST_TIMEOUT).
> 
> For this specific XTF test, I am not sure it is worth optimizing the
> timeout, maybe we should leave it as default. 

The default of 25min is quite wasteful for XTF test that failed...

> However if we wanted to
> lower the timeout value, overwriting it the way you did is OKish as I
> cannot think of another way.

If we'd need this option more often, Maybe we could set
TEST_TIMEOUT_OVERRIDE in test yaml, and then test script use that (if
present) instead? Or maybe have few "classes" of timeouts set globally
(TEST_TIMEOUT_SHORT, TEST_TIMEOUT_MEDIUM, TEST_TIMEOUT_LONG? or some
better named categories). But I don't think it's worth it for this XTF
test yet.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2024-10-03  0:25 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-02 12:42 [PATCH 1/2] automation: preserve built xen.efi Marek Marczykowski-Górecki
2024-10-02 12:42 ` [PATCH 2/2] automation: add a smoke test for xen.efi on X86 Marek Marczykowski-Górecki
2024-10-02 21:03   ` Andrew Cooper
2024-10-02 22:16   ` Stefano Stabellini
2024-10-02 22:22     ` Stefano Stabellini
2024-10-02 22:55       ` Marek Marczykowski-Górecki
2024-10-02 23:08         ` Andrew Cooper
2024-10-02 23:30         ` Stefano Stabellini
2024-10-03  0:24           ` Marek Marczykowski-Górecki [this message]
2024-10-03  0:32             ` Stefano Stabellini
2024-10-03 20:24               ` Stefano Stabellini
2024-10-02 20:42 ` [PATCH 1/2] automation: preserve built xen.efi Andrew Cooper
2024-10-02 20:46   ` Marek Marczykowski-Górecki
2024-10-02 22:16     ` Stefano Stabellini

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=Zv3kVEljCcM-Ww91@mail-itl \
    --to=marmarek@invisiblethingslab.com \
    --cc=cardoe@cardoe.com \
    --cc=sstabellini@kernel.org \
    --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.