qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 0/3] fix build failures from incorrectly skipped container bu


From: Stefan Weil
Subject: Re: [PATCH 0/3] fix build failures from incorrectly skipped container build jobs
Date: Tue, 9 Feb 2021 07:01:49 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.7.0

Am 08.02.21 um 19:12 schrieb Daniel P. Berrangé:

On Mon, Feb 08, 2021 at 07:08:39PM +0100, Philippe Mathieu-Daudé wrote:
On 2/8/21 6:22 PM, Daniel P. Berrangé wrote:
On Mon, Feb 08, 2021 at 04:33:36PM +0000, Daniel P. Berrangé wrote:
This series fixes a problem with our gitlab CI rules that cause
container builds to be skipped. See the commit description in the
first patch for the details on this problem.

The overall result of this series though is a small increase in overall
pipeline time.

Previously

  - When container jobs are skipped: approx 1hr 5 mins
  - When container jobs are run, cached by docker: approx 1hr 15 mins
  - When container jobs are run, not cached by docker: approx 1hr 30 mins

With this series applied the first scenario no longer exists, so
all piplines are either 1hr 15 or 1hr 30 depending on whether the
container phase is skipped.
I mean to say the biggest problem I see is the cross-win64-system
job. This consumes 1 hour 5 minutes all on its own. It is at least
15 minutes longer that every other job AFAICT. So no matter how
well we parallelize stuff, 1 hr 5 is a hard lower limit on pipeline
duration right now.

We might want to consider how to split the win64 job or cut down
what it does in some way ?
When the win64 build was added (on Debian), it was to mostly to cover
the WHPX. Later we moved mingw jobs to Fedora. I just checked and
WHPX is no more built, and nobody complained, so it is not relevant
anymore.

I don't mind much what you do with the Gitlab win64 job, as this config
is better covered on Cirrus. I'd like to keep the win32 job because it
has been useful to catch 32-bit issues.
I'm not suggesting we remove it. Most developers won't setup Cirrus CI,
so will only run GitLab CI jobs.  IME it is good to have both win32
and win64 coverage because things do break differently on them - especially
if you use bad printf format strings that are not independant of host
word size


I would not say that something is not relevant just because nobody complains. Nobody would miss any CI if everything were always fine. So people would miss WHPX CI as soon as there are changes (which happen infrequently) and something breaks. WHPX should be covered by the w64 build, and as many as possible other features where I currently see a "NO" in the configure output as well.

Nevertheless I don't think that each CI job must run frequently. Each run not only costs time, but also energy, and contributes to our climate change.

I think that for the win32 and win64 jobs it would be sufficient to run them weekly, maybe even alternating if that is possible.

Stefan






reply via email to

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