Testing Farms is ready, we have CentOS-Stream-9 compose around used by others.

@msrb can we map epel-9 and epel-9-next to it pls?

https://src.fedoraproject.org/rpms/python-virtualenv/pull-request/57 is a nice example to test this on.

Fedora CI - scratch build errors, Zuul does not seem to start at all (cc @fbo).

yeah, I guess this affects both Zuul and Fedora CI and we should fix both.

@churchyard Hi, yes again trouble with our cloud provider. The node that manage containerized jobs for Zuul (like rpm-scratch-build) is unreacheable. A ticket is opened and now we are waiting for feedback from the cloud provider.

The first step for Fedora CI is to be able to mock-build SRPMs, and there is no mock config for EPEL 9 on CI machines yet. I see there is an update in Bodhi which adds the config, but it seems like it won't make it to stable repositories: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-2d0f959e00

Once mock configs are sorted out, we can move forward with this.

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-2d0f959e00 is stable

@fbo can you check if this now works with epel?

Hi I cannot work on that support right now but I'll create a story for our next team sprint.

However I took a bit of time to improve the FZCI documentation, so adding the epel9 support based on the existing config for epel8 should be feasible for someone that'd like to contribute to FZCI config.

If the process described in the README.md is missing information then please tell me and I'll fix it.

Doc here: https://pagure.io/fedora-project-config

@fbo pls review https://pagure.io/fedora-project-config/pull-request/190

This has been merged. Does anyone have a change to trigger on epel9 branch ?

I've rebased https://src.fedoraproject.org/rpms/python-virtualenv/pull-request/57

rpm-test : POST_FAILURE in 2m 14s
rpm-sti-test : SUCCESS in 8m 34s

It seems this package is not available on stream9 "No package standard-test-roles available"

@mvadkert and @msrb from where do you install it for the TMT job ?

@fbo we do not have standard-test-roles installed in the test environment, we have it on the test runner (centos 8 based) :( ansible runs against the remote VM

@astepano can we build STR for epel 9 pls?

Or maybe we could just drop this and execute STI tests only via rpm-sti-test ?

Or maybe we could just drop this and execute STI tests only via rpm-sti-test ?

Please don't, rpm-sti-test does not expose our custom artifacts, that would be a serious regression for us. https://pagure.io/fedora-ci/general/issue/301

We extended the time the for artifacts, they are now kept to 90 days, you should be able to find all artifacts in the exposed workdir. Can you give me a recent run so I can check pls? Then I guess it is just matter of documentation.

AHA, we do not expose that link for STI ... so let me fix that.

For https://artifacts.dev.testing-farm.io/cfef9bdc-26c1-4eeb-925b-58d0e9daa77f/

What artifacts are you expecting?

Looking at ansible log:

https://artifacts.dev.testing-farm.io/cfef9bdc-26c1-4eeb-925b-58d0e9daa77f/work-tests.ymlWr58vO/ansible-output.txt

This is not a good example?

No, this is not a good example.

See e.g. https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/268 -- I want https://fedora.softwarefactory-project.io/logs/68/268/b26e5be4a1926b61f4518ca6b363a03eca8f01c6/check/rpm-test/d61971b/artifacts/

@churchyard ack, it is archived:

https://artifacts.dev.testing-farm.io/80d3e5ed-afad-4d4b-8a09-90109eec636e/work-tests.yml9dV6nx/tests-sCz3VE/

Except the RPMs but I guess that is not such an issue?

It is badly discoverable, I will add artifacts storage link as we have there with tmt. It is a bit more clicking then with Zuul, but at least something ...

Aha, rpms are removed from artifacts storage by us, we can omit that removal ...

Except the RPMs but I guess that is not such an issue?

I need to inspect the RPMs sometimes. That's the point of adding them to artifacts. (But we are offtopic here, the issue is https://pagure.io/fedora-ci/general/issue/301)

Conclusion: If https://pagure.io/fedora-ci/general/issue/301is solved, we won't need rpm-test on Zuul I guess.

Agreed, as I said, we will provide a link like this:

http://artifacts.osci.redhat.com/testing-farm/ac685e43-1da9-40f5-a6d0-3aac83fb4dfa/work-buildjL_KFt

In the html as we have for tmt, that at least makes the link discoverable:

http://artifacts.osci.redhat.com/testing-farm/ac685e43-1da9-40f5-a6d0-3aac83fb4dfa/

I Agree to remove rpm-test job as soon as 301 is solved.

Since this is opened for 9 months and the last comment here was 5 months ago, I decided to poke the current state of things again. Looking at https://src.fedoraproject.org/rpms/python-tox/pull-request/103 which is an epel9 PR.

• Fedora CI - scratch build run on epel9 target, which is correct :heavy_check_mark:
• Fedora CI - dist-git test either have not started or never reported back :x:
• Zuul rpm-scratch-build run on epel9 target, which is correct :heavy_check_mark:
• Zuul rpm-test still is POST_FAILURE and that renders the entire Zuul result to be a failure :x:
• Zuul rpm-sti-test runs on CentOS Stream 9 which is a tad bad but not entirely :question: