From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Gerd Hoffmann <kraxel@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 12:53:00 +0200 [thread overview]
Message-ID: <a1ec5724-bebd-3fe7-a1a2-db8065266feb@redhat.com> (raw)
In-Reply-To: <20200914095438.wkc2fou3ijrctmfl@sirius.home.kraxel.org>
+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.
Usually git-forge based projects keep release builds forever.
In our case we are interested in updating them during the development
window, to be well tested on release.
Also we need to modify the source tarball generator script to fetch
the artifacts and include them, isn't it?
> Can we build all our firmware in CI,
> using the shared gitlab x86 runners and cross compilers?
I'm pretty sure. In case something is missing, adding it shouldn't
be a problem anyway.
Regards,
Phil.
next prev parent reply other threads:[~2020-09-14 10:54 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é [this message]
2020-09-14 11:40 ` Gerd Hoffmann
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=a1ec5724-bebd-3fe7-a1a2-db8065266feb@redhat.com \
--to=philmd@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=berrange@redhat.com \
--cc=brogers@suse.com \
--cc=kraxel@redhat.com \
--cc=lersek@redhat.com \
--cc=mjt@tls.msk.ru \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).