From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.5047.1650439849133008911 for ; Wed, 20 Apr 2022 00:30:49 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=bobxk6a3; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1650439848; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=D+sb84DF6HfBMP4WoyoUkRj+MjlZWA3itVAe9P67Nec=; b=bobxk6a3BwlUV70TgdrkRcDQUJOu7P7LOUM4E4FuGt71cdiHQdVIA4gzVCXNDWmiwai2W4 gt8cPPcBi5o5Zy5OfczaFXzuE8ChPE8p26vzcAhPURMuNLzStjmHvF0xnBZDxyCbU1avz6 FAa1pQfdGhhpWACaranJWpkBvf+aZ1A= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-654-bnBMb8_xP76XWRggrALufQ-1; Wed, 20 Apr 2022 03:30:44 -0400 X-MC-Unique: bnBMb8_xP76XWRggrALufQ-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7B8BF1014A77; Wed, 20 Apr 2022 07:30:43 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.9]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E0AAE572345; Wed, 20 Apr 2022 07:30:42 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id BA888180009C; Wed, 20 Apr 2022 09:30:40 +0200 (CEST) Date: Wed, 20 Apr 2022 09:30:40 +0200 From: "Gerd Hoffmann" To: Ard Biesheuvel Cc: Oliver Steffen , Andrew Fish , Ard Biesheuvel , "Feng, Bob C" , Bret Barkelew , edk2-devel-groups-io , "Liming Gao (Byosoft address)" , Jiewen Yao , Jordan Justen , Michael Kinney , Leif Lindholm , Ray Ni , Sami Mujawar , Sean Brogan , Yuwei Chen Subject: Re: [PATCH 0/4] CI: Use Fedora 35 container for Linux jobs Message-ID: <20220420073040.d3dpwzt4hwhm3hg5@sirius.home.kraxel.org> References: <20220419073448.165566-1-osteffen@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 19, 2022 at 11:54:38PM +0200, Ard Biesheuvel wrote: > On Tue, 19 Apr 2022 at 09:35, Oliver Steffen wrote: > > > > PR: https://github.com/tianocore/edk2/pull/2711 > > > > Update CI, run all Linux (aka Ubuntu-GCC5) based jobs in a custom > > Fedora 35 container. > > Why? > > > The image provides gcc 11 from Fedora for all > > architectures. The external dependencies for gcc have been removed > > so stuart does not download them. iasl and nasm are also > > included in the image, but remain as ext-dep for now (CI jobs on > > Windows need those). ^^^ this for example. The idea is to (a) switch linux CI builds from vm images to container images, and (b) use our own, custom container images. This allows to roll the dependencies needed for CI into the container images, so there is no need to download them in CI jobs. Fixes temporary CI failures due to network problems and download errors. This also allows to remove any distribution-specific commands (apt-get for example) from CI jobs. This will be handled in the Dockerfiles used to build our custom container images instead. Oliver is also working on ubuntu containers, look here: > > The Dockerfiles are here: > > https://github.com/osteffenrh/edk2-build-images, Fedora is a bit faster on updating stuff. For example: ubuntu 22.04 uses gcc 11 whereas Fedora 36 uses gcc 12 (both distros are in beta right now). Whenever we want: (a) stick to ubuntu, or (b) switch to fedora, or (c) use both is up for debate. > > but they should, of > > course, then move to a repo in the Tianocore group, or something like > > that. The images are built automatically via GitHub Actions and then > > pushed to ghcr.io. That is the next question: where should we host the Dockerfiles and container images? For the Dockerfiles that should probably a git repo in the tianocore group. For the container images the obvious choices are github and azure. Given that microsoft owns github I'd expect both github actions and azure pipelines are running on the same cloud infrastructure and it doesn't make much of a difference whenever github or azure container registry is used to host container images. take care, Gerd