[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/3] fix build failures from incorrectly skipped container bu
Re: [PATCH 0/3] fix build failures from incorrectly skipped container build jobs
Mon, 8 Feb 2021 19:08:39 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
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.
>> - 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
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.
Re: [PATCH 0/3] fix build failures from incorrectly skipped container build jobs, Philippe Mathieu-Daudé, 2021/02/16