All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Thomas Huth <thuth@redhat.com>
Cc: "Philippe Mathieu-Daudé" <f4bug@amsat.org>, qemu-devel@nongnu.org
Subject: Re: [PATCH] gitlab-ci: Remove unused container images
Date: Sat, 20 Feb 2021 21:11:44 +0000	[thread overview]
Message-ID: <87tuq6jvd6.fsf@linaro.org> (raw)
In-Reply-To: <c429f806-ae37-9939-d215-fe98bffb84dd@redhat.com>


Thomas Huth <thuth@redhat.com> writes:

> On 19/02/2021 13.00, Philippe Mathieu-Daudé wrote:
>> On 2/19/21 12:09 PM, Thomas Huth wrote:
>>> We're building a lot of containers in the gitlab-CI that we never use.
>>> This takes away network bandwidth and CPU time from other jobs for no
>>> use, so let's remove them for now. The individual containers could be
>>> re-added later when we really need them.
>>>
>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>> ---
>>>   .gitlab-ci.d/containers.yml | 92 -------------------------------------
>>>   1 file changed, 92 deletions(-)
>> 
>> I'm not enthusiast with this patch because I use various in this list
>> from time to time for testing or cross build/disas binaries.
>
> When I look at our current huge list of containers, I wonder how do we know 
> which containers still get used (in the sense of not only build), and which 
> ones are likely already bit-rotten? And why do we need that many containers? 
> Why both, debian-arm64-test-cross.docker and debian-arm64-cross.docker and 
> not combine them?

debian64-arm64-test-cross is based of testing because we need a newer
GCC than the QEMU cross compiler to build the SVE and MTE tests for
aarch64 check-tcg.

> And why do we need that many individual cross-compiler 
> docker files if we already have debian-all-test-cross.docker that can be 
> used to test most of them? ... for me, as a docker ignorant, this is all 
> very opaque and some clean up IMHO could really help here.

Because it's quite heavyweight for users who may only be building one or
two arches to pull down all the compilers in one image.

>
>> Not having
>> these containers used mainstream probably show the failure of the
>> project to add good testing coverage on these targets. Most of them are
>> for hobbyist with little time. Removing them will make it even harder
>> to add tests.
>
> Do you really use the docker files from the gitlab registry? I'd rather 
> expected that people build those locally in case they need them...?
>
>> Can't we keep them disabled? Or put them in manual mode?
>
> Well, I guess manual mode is fine, too, as long as they don't waste CPU 
> cycles and network bandwidth anymore for most people who don't need them.
>
>   Thomas


-- 
Alex Bennée


  parent reply	other threads:[~2021-02-20 21:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-19 11:09 [PATCH] gitlab-ci: Remove unused container images Thomas Huth
2021-02-19 11:40 ` Daniel P. Berrangé
2021-02-19 12:00 ` Philippe Mathieu-Daudé
2021-02-19 12:08   ` Daniel P. Berrangé
2021-02-19 13:10   ` Thomas Huth
2021-02-19 13:41     ` Philippe Mathieu-Daudé
2021-02-20 21:11     ` Alex Bennée [this message]
2021-02-20 21:10 ` Alex Bennée
2021-02-21  8:39   ` Philippe Mathieu-Daudé
2021-02-22  5:31   ` Thomas Huth
2021-02-22  8:44     ` Alex Bennée

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=87tuq6jvd6.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=f4bug@amsat.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /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.