Re: [edk2-discuss] [edk2-devel] Soft Feature Freeze starts now for edk2-stable202311

["Pedro Falcato" <pedro.falcato@gmail.com>]

On Wed, Nov 22, 2023 at 1:49 PM Leif Lindholm <quic_llindhol@quicinc.com> wrote:
>
> On 2023-11-22 13:21, Marcin Juszkiewicz wrote:
> > W dniu 22.11.2023 o 13:26, Leif Lindholm pisze:
> >> On 2023-11-22 11:11, Sami Mujawar wrote:
> >
> >>> [SAMI] The proposal above looks good to me. This may be slightly off
> >>> topic, but can we also enable edk2-platform upstream CI as well,
> >>> please? This would be helpful to catch issues much earlier. [/SAMI]
> >
> >> Yes, this is a problem we need to solve, but we don't have the time or
> >> resources to set up an upstream CI. What we've been thinking of
> >> is to let maintainers set up their own CI infrastructure and then
> >> have that perform any target-specific tasks and report back to
> >> upstream CI. It's been a few months since I last discussed this with
> >> Mike, but I think we were looking at
> >> https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners
> >> as a possible tool.
> >>
> >> This is probably not something we would like to tie into the edk2
> >> mergify workflow (it would add too much delay), but localised to
> >> edk2-platforms.
> >>
> >> Any help with implementing that would be most appreciated :)
> >
> > I can write CI jobs which would run tests for QEMU platforms:
> >
> > - virt/x86-64 (i440fx/q35)
> > - virt/aarch64
>
> These live in the main edk2 repo though, so are not part of the problem
> that needs solving.
>
> > - sbsa-ref/aarch64
> >
> > Sbsa-ref is something I am working on daily.
> >
> > If Github Actions is all what's needed then it can be done using
> > platform provided runners (no self-hosted needed).
>
> We need the self-hosted for the physical platforms, which are the main
> part of the problem. But setting something like this up for the
> edk2-platforms platforms we can test with qemu could be a good first step.

FWIW, QemuOpenBoardPkg and Ext4Pkg could also easily be tested with GitHub CI.
A problem with the current development model is that edk2-platforms
maintainers just push to master[1]. This is inherently CI-unfriendly.

I would have no problems maintaining my own repo and merging back
every once in a while, with a GitHub PR that would indeed go through
CI before merging. And this seems like the less painful solution,
compared to all the trouble EDK2 core has had with submitting changes,
etc, which I really do NOT want to deal with.

--
Pedro

[1] There's also the problem of knowing what edk2.git your
platform/feature package works with. Mine always aim for edk2.git
HEAD.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111622): https://edk2.groups.io/g/devel/message/111622
Mute This Topic: https://groups.io/mt/102746762/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-