On Wed, Nov 13, 2024 at 12:38 PM František Lachman <flachman@xxxxxxxxxx> 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@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
