I guess this is duplicate of https://pagure.io/fedora-ci/general/issue/338 so feel free to close one of them.

Interesting, well, I guess those should be just tested against CentOS Stream 9 right?

Testing Farm should be ready then, we just need to fix the mapping to correct compose?

I think we might be talking about two separate things.

The scratch builds need need to happen against the epel8-next / epel9-next Koji targets. I assume it's a relatively simple change to set the appropriate mapping from distgit branch to Koji target.

The Testing Farm jobs need to run on a CentOS Stream 8/9 VM with the epel-release and epel-next-release packages installed.

I'd appreciate if this could be addressed in the relatively near future. For the ansible package, I've adopted the PR first workflow and wrote TMT and gating tests. It's a big wrinkle that nothing works on EPEL Next.

Definitely, sorry for the delay :( seems like a low hanging fruit :(

@msrb could you check why scratch build was built against Fedora pls in:

https://koji.fedoraproject.org/koji/taskinfo?taskID=101522704

And make it run against CentOS Stream 9? Same sitation for Cs8 is needed, see https://pagure.io/fedora-ci/general/issue/338

@fbo Is the scratch build building something you can fix?

I will look at the mapping of epel[89]-next to correct compose in TF.

Definitely, sorry for the delay :( seems like a low hanging fruit :(

Thanks! Sorry my comment was a bit grumpy :).

@msrb could you check why scratch build was built against Fedora pls in:

I opened https://github.com/fedora-ci/dist-git-build-pipeline/pull/35 to (assuming I did it correctly :) fix the Fedora CI scratch build part.

@gotmax23 Thank you for the pull request -- merged together with other changes ;)

Scratch builds seem to be working now:
https://src.fedoraproject.org/rpms/ansible/pull-request/63
https://koji.fedoraproject.org/koji/taskinfo?taskID=101713174

However, tests fail:
https://artifacts.dev.testing-farm.io/070e2ec7-a6cb-467a-906c-7e3d50b7bf2d/

+ ansible -c local -i locahost, localhost -b -m community.general.copr -a 'name=gotmax23/community.general.copr_integration_tests chroot=fedora-rawhide-x86_64'
+ tee out
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: ModuleNotFoundError: No module named 'dnf'

thanks for working that out @msrb !

I will try to look at Zuul next week, seems now koji is even down :(

@gotmax23 Thank you for the pull request -- merged together with other changes ;)

Sure! Thanks for fixing my mistake. I'm not super familiar with the Jenkins groovy stuff :).

Scratch builds seem to be working now:
https://src.fedoraproject.org/rpms/ansible/pull-request/63
https://koji.fedoraproject.org/koji/taskinfo?taskID=101713174

However, tests fail:
https://artifacts.dev.testing-farm.io/070e2ec7-a6cb-467a-906c-7e3d50b7bf2d/
+ ansible -c local -i locahost, localhost -b -m community.general.copr -a 'name=gotmax23/community.general.copr_integration_tests chroot=fedora-rawhide-x86_64' + tee out An exception occurred during task execution. To see the full traceback, use -vvv. The error was: ModuleNotFoundError: No module named 'dnf'

That's a problem with the tests and not with the infrastructure. Other than (https://github.com/fedora-ci/dist-git-pipeline/pull/52#issuecomment-1572385515), it seems the Fedora CI portion is working as expected. Thanks!

Hi,

Regarding Zuul here are three changes to enable epel9-next branch support:

• https://pagure.io/fedora-project-config/pull-request/275
• https://pagure.io/fedora-zuul-jobs/pull-request/176 (auto generated from fedora-project-config/pull-request/275)
• https://pagure.io/fedora-zuul-jobs-config/pull-request/177 (auto generated from fedora-project-config/pull-request/275)

Please, I've let some comments on the auto-generated PR, for you to double check the settings.

Cool, thanks! Would it make sense to also include epel8-next in these PRs or would it be easier separately?

For epel8-next I'll do it with with a follow-up change. What about epel8 and epel9 targets are they still relevant ?

What about epel8 and epel9 targets are they still relevant ?

Yes, those are still relevant. Scratch builds for epel8 and epel9 should run against their respective Koji targets and STI and FMF tests running on Testing Farm should use RHEL 8 and 9 instances.

(See https://docs.fedoraproject.org/en-US/epel/epel-about-next/ if you'd like more context about EPEL vs EPEL Next)

For epel8-next I'll do it with with a follow-up change.

Sounds good. Thanks!

Hi,

Thanks for the review. I've updated the changes according to the review. Then merged the changes. Could you please ensure that Zuul behaves as expected for epel9-next branch.

When I get the confirmation that for epel9-next branch we are OK, then I'll start the change for epel8-next support.

@gotmax23 can you expand more on the need of RHEL8 / RHEL9? We do not support testing against these distros in public. We use Cs8 and Cs9.

@gotmax23 can you expand more on the need of RHEL8 / RHEL9? We do not support testing against these distros in public. We use Cs8 and Cs9.

See @carlwgeorge's comment here: https://github.com/fedora-ci/dist-git-pipeline/pull/52#issuecomment-1574288980.

Side note: it's a problem that the Koji buildroot repositories (e.g https://kojipkgs.fedoraproject.org/repos/epel9-build/latest/) are being used for plain epelX in the TF and instability (rpm-install-test Zuul job) tests. The epelX buildroot repositories are unusable, as they contain layered packages from Fedora Infra's private RHEL mirror. I think we'll need to set the plain epelX branches to use composed content until https://pagure.io/epel/issue/200 is resolved. The epelX-next branches can keep using the buildroot repositories, as those are not susceptible to this problem.

When I get the confirmation that for epel9-next branch we are OK, then I'll start the change for epel8-next support.

I think we can go ahead and enable epel8-next support