Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 9, 2023 at 6:19 AM Peter Robinson <pbrobinson@xxxxxxxxx> wrote:
>
> On Mon, May 8, 2023 at 9:11 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote:
> >
> > On Mon, May 08, 2023 at 07:57:30PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > >
> > > I think we need some clarity wrt. to the dependency order here.
> > > Let's say we:
> > > > In order to do this at branch point, we will need to move building this
> > > > image into the compose process and mark it blocking.
> > > OK, so we build things, but then we need to publish to registry.fp.o,
> > > which is asynchrounous (?). When we test the newly built ISOs, do
> >
> > No, it happens at the end of the compose (if no blocking deliverables
> > failed causing the compose to fail)
> >
> > > we test them also with the latest image that we get from registry.fp.o?
> > > And if we find a bug anywhere in this pipeline, we respin everything?
> >
> > Good question. I'll note that currently we do not do any specific
> > testing after branch point. We freeze things to get a compose to
> > complete, but then we move on. It's not like Beta or Final.
> >
> > > > I'd like to note that making this blocking doesn't waive any kind of
> > > > magic wand that makes our infrastructure more reliable. ;)
> > > > The container build pipeline is a long collection of fragile things.
> > > > It may well result in us slipping more based on things not working. ;(
> > >
> > > Hmm, quoting from https://pagure.io/releng/issue/11092:
> > > >> Also the aarch64 cluster is running on Fedora 33 boxes, so we
> > > >> should probably try to do a full redeploy :-(
> > > > We can't upgrade it from f33 because docker is no longer in f34+ and
> > > > openshift origin / 3.11 doesn't support any newer either.
> > >
> > > Is this still true? I don't think we want to make the Fedora release
> > > process contingent on something that requires F33.
> >
> > yes, it's still true. Note thats the aarch64 osbs cluster.
> > The x86_64 one is rhel7.
> >
> > So, perhaps it would make sense to only make the x86_64 one blocking?
>
> Or possibly build it with osbuild, the infra there is pretty stable
> now for IoT, it's not perfect, but it does have x86_64/aarch64.

We have multiple options that aren't the OSBS stuff:

* kiwi (there's a koji plugin for it)
* osbuild
* lorax

I'd be happy to help with kiwi (as one of the upstream developers of it).

The Fedora Asahi, CentOS Hyperscale, and CentOS Alternative Image
teams have been using kiwi to build images for a while now. :)




--
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux