On Wed, Nov 13, 2024 at 12:38 PM František Lachman <flach...@redhat.com> wrote:
> Hi Nikita, > > I can't speak on behalf of Fedora CI or Zuul but I want to mention that in > the Packit team[0], we are trying to help in this situation of not having > much capacity to maintain existing CI solutions for dist-git. > > Since Packit already have a (quite advanced) integration for the Testing > Farm to be run on GitHub/GitLab pull requests, we decided to provide the > same for dist-git pull-requests as well so there is the same experience in > upstream and downstream. The code is mostly ready, but the hardest part is > to agree on how to enable/tweak workflow (or if we should make it the > default). And we are really happy to get feedback like this so we can learn > from it from the very start. > > The current plan is to provide a prototype people can play with by the end > of the year. > If you want to follow our work, we have an epic for this here: > https://github.com/packit/packit-service/issues/2453 > > A small note to avoid confusion: > This is independent of Packit's Fedora release automation. We can even > give this a different branding. > The thing that the Packit team will maintain the CI service and share a > significant part of the code with Packit might be read as a technical > detail. > And since we use Testing Farm to run actual tests, no change in test > definitions (thanks to tmt) should be needed. > Thanks, this sounds promising. We'd be happy to give this a try when it becomes available. I found this document with a bit more info than the issue: https://github.com/packit/research/blob/main/research/integrations/fedora-ci/index.md I'm not really familiar with packit's existing CI integrations -- do they abort pending builds on new pushes, or do they continue running like in Fedora CI / Zuul? And just a few notes on the Koji Scratch build overload: > * We are coordinating this effort with the Testing Farm team (that > currently manages Zuul and is trying to deprecate[1] Fedora-CI). If/when > Packit provides this functionality, the other two might be disabled (either > in general or per-package). > Yeah, we wouldn't really be able to use the packit-based CI (at least longer term) if we can't disable the old Fedora CI somehow, otherwise people will yell at us again :) > * Packit could use Copr instead to provide RPMs but this change of build > system between CI and reality is probably not wanted. > Yes, I agree that it's important to use the same build infrastructure as the "real" builds. For LLVM, we hit a different set of issues for each of copr, fedora koji, centos stream koji and rhel brew. The hardware pool is different each time and that can make a big difference for things like openmp tests. Regards, Nikita
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
