From: Gerd Hoffmann <kraxel@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: "Thomas Huth" <thuth@redhat.com>,
"Daniel P . Berrange" <berrange@redhat.com>,
"Laszlo Ersek" <lersek@redhat.com>,
"Michael Tokarev" <mjt@tls.msk.ru>,
"qemu devel list" <qemu-devel@nongnu.org>,
"Bruce Rogers" <brogers@suse.com>,
"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [PATCH 08/10] pc-bios: refresh edk2 build artifacts for edk2-stable202008
Date: Mon, 14 Sep 2020 13:40:05 +0200 [thread overview]
Message-ID: <20200914114005.z23yjc4wbqem4reh@sirius.home.kraxel.org> (raw)
In-Reply-To: <a1ec5724-bebd-3fe7-a1a2-db8065266feb@redhat.com>
On Mon, Sep 14, 2020 at 12:53:00PM +0200, Philippe Mathieu-Daudé wrote:
> +Michael & Bruce
>
> On 9/14/20 11:54 AM, Gerd Hoffmann wrote:
> > Hi,
> >
> >> The CI idea is to have reproducible builds if possible.
> >> When the submodule is updated (or the QEMU scripts containing the
> >> -D defines), it triggers the 'build-edk2' job which produce these
> >> same binaries.
> >> My original idea was to push the tag on GitLab that triggers the
> >> job, then download the produced binaries, test them, then commit
> >> them.
> >
> > Now with CI in place we maybe should step back and have a look at the
> > big picture.
> >
> > Should we simply stop committing firmware binaries into git and provide
> > them as CI artifacts instead?
>
> What I'm not sure about is how to keep the built artifacts forever.
Dunno. gitlab has support for various packages and container images,
but not for tarballs or rpms or raw binaries. Possibly we could publish
them as gitlab pages.
> Also we need to modify the source tarball generator script to fetch
> the artifacts and include them, isn't it?
An firmware download script certainly makes sense.
Whenever we want continue including the firmware in the tarballs when
we dropped it from the git repo is up for debate ;)
take care,
Gerd
next prev parent reply other threads:[~2020-09-14 11:42 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-08 7:29 [PATCH 00/10] edk2: adopt the edk2-stable202008 release Laszlo Ersek
2020-09-08 7:29 ` [PATCH 01/10] Makefile: remove obsolete edk2 exception from "clean" rule Laszlo Ersek
2020-09-08 8:13 ` Philippe Mathieu-Daudé
2020-09-08 7:29 ` [PATCH 02/10] roms/efirom, tests/uefi-test-tools: update edk2's own submodules first Laszlo Ersek
2020-09-08 7:29 ` [PATCH 03/10] roms/Makefile.edk2: prepare for replacing TPM2*_ENABLE macros Laszlo Ersek
2020-09-08 8:09 ` Philippe Mathieu-Daudé
2020-09-08 7:29 ` [PATCH 04/10] tests: acpi: tolerate "virt/SSDT.memhp" mismatch temporarily Laszlo Ersek
2020-09-08 8:56 ` Igor Mammedov
2020-09-08 12:02 ` Michael S. Tsirkin
2020-09-08 7:29 ` [PATCH 05/10] roms/edk2: update submodule from edk2-stable201905 to edk2-stable202008 Laszlo Ersek
2020-09-08 8:22 ` Philippe Mathieu-Daudé
2020-09-08 12:08 ` Laszlo Ersek
2020-09-10 15:32 ` Philippe Mathieu-Daudé
2020-09-10 15:44 ` Laszlo Ersek
2020-09-10 16:00 ` Philippe Mathieu-Daudé
2020-09-10 16:14 ` Laszlo Ersek
2020-09-08 7:29 ` [PATCH 06/10] roms/Makefile.edk2: complete replacing TPM2*_ENABLE macros Laszlo Ersek
2020-09-08 8:10 ` Philippe Mathieu-Daudé
2020-09-08 7:29 ` [PATCH 07/10] roms/Makefile.edk2: enable new ARM/AARCH64 flags up to edk2-stable202008 Laszlo Ersek
2020-09-08 8:11 ` Philippe Mathieu-Daudé
2020-09-08 7:29 ` [PATCH 08/10] pc-bios: refresh edk2 build artifacts for edk2-stable202008 Laszlo Ersek
2020-09-10 16:32 ` Philippe Mathieu-Daudé
2020-09-10 16:40 ` Daniel P. Berrangé
2020-09-10 17:16 ` Laszlo Ersek
2020-09-14 9:54 ` Gerd Hoffmann
2020-09-14 10:53 ` Philippe Mathieu-Daudé
2020-09-14 11:40 ` Gerd Hoffmann [this message]
2020-09-08 7:29 ` [PATCH 09/10] pc-bios: update the README file with edk2-stable202008 information Laszlo Ersek
2020-09-10 16:03 ` Philippe Mathieu-Daudé
2020-09-08 7:29 ` [PATCH 10/10] tests: acpi: update "virt/SSDT.memhp" for edk2-stable202008 Laszlo Ersek
2020-09-08 8:27 ` Philippe Mathieu-Daudé
2020-09-08 12:14 ` Laszlo Ersek
2020-09-10 16:02 ` Philippe Mathieu-Daudé
2020-09-08 8:56 ` Igor Mammedov
2020-09-08 12:03 ` Michael S. Tsirkin
2020-09-10 19:31 ` [PATCH 00/10] edk2: adopt the edk2-stable202008 release Philippe Mathieu-Daudé
2020-09-11 7:12 ` Laszlo Ersek
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=20200914114005.z23yjc4wbqem4reh@sirius.home.kraxel.org \
--to=kraxel@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=berrange@redhat.com \
--cc=brogers@suse.com \
--cc=lersek@redhat.com \
--cc=mjt@tls.msk.ru \
--cc=philmd@redhat.com \
--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.