qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PULL 00/13] testing updates (gitlab, cirrus, docker, avocado, windo


From: Peter Maydell
Subject: Re: [PULL 00/13] testing updates (gitlab, cirrus, docker, avocado, windows)
Date: Sun, 26 Feb 2023 20:13:27 +0000

On Fri, 24 Feb 2023 at 21:23, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>
> On 24/2/23 20:52, Alex Bennée wrote:
> >
> > Peter Maydell <peter.maydell@linaro.org> writes:
> >
> >> On Thu, 23 Feb 2023 at 15:57, Alex Bennée <alex.bennee@linaro.org> wrote:
> >>>
> >>> The following changes since commit 
> >>> 79b677d658d3d35e1e776826ac4abb28cdce69b8:
> >>>
> >>>    Merge tag 'net-pull-request' of https://github.com/jasowang/qemu
> >>> into staging (2023-02-21 11:28:31 +0000)
> >>>
> >>> are available in the Git repository at:
> >>>
> >>>    https://gitlab.com/stsquad/qemu.git tags/pull-testing-next-230223-1
> >>>
> >>> for you to fetch changes up to e9969376f01180d7bcbee25ae8333983da7eda2c:
> >>>
> >>>    cirrus.yml: Improve the windows_msys2_task (2023-02-23 15:48:23 +0000)
> >>>
> >>> ----------------------------------------------------------------
> >>> testing updates:
> >>>
> >>>    - ensure socat available for tests
> >>>    - skip socat tests for MacOS
> >>>    - properly clean up fifos after use
> >>>    - make fp-test less chatty
> >>>    - store test artefacts on Cirrus
> >>>    - control custom runners with QEMU_CI knobs
> >>>    - disable benchmark runs under tsan build
> >>>    - update ubuntu 2004 to 2204
> >>>    - skip nios2 kernel replay test
> >>>    - add tuxrun baselines to avocado
> >>>    - binary build of tricore tools
> >>>    - export test results on cross builds
> >>>    - improve windows builds
> >>>
> >>> ----------------------------------------------------------------
> >>
> >> So I've been applying pullreqs relying on a combination of the
> >> private-runner CI jobs plus using the free minutes allowance
> >> on my personal gitlab account, and ad-hoc local builds. I'm
> >> a bit reluctant to do that for this one though, because it's
> >> touching all the gitlab config and we won't be able test that
> >> that is OK until we can do a full run with the standard config.
> >> What do you think ?
>
> What is the alternative, waiting 5 days up to March 1st?

That would be the other option, yes.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]