See also https://src.fedoraproject.org/tests/python/pull-request/1#comment-12484

and python3-devel

Why are we testing 3.6 form the 3.7 package repo?

Where do i see it in action?

Just wanted to show how this can be used as an integration test for components related to multiple python versions.

python3-devel is a dependency of python3-tox
Do you want to have it listed explicitly anyway?

I believe it would be better to list it explicitly, Miro what do you think?

yes. tox is needed jut to test the tox part. if we ever decide not to test the tox part, we would remove tox and things would break. Adding explicit requirement on python3-devel is better. also, it is probably only recommended.

Well, in that case, can this yml be in the shared repo? or how does that work, when is it going to be run?

[citest]

Thanks for the feedback. I've updated the PR to run against Python 3.7 only and explicitly require python3-devel as well. The tests.yml file needs to be in the package dist repo as this is how the test discovery is defined by the Standard Test Interface:

• https://fedoraproject.org/wiki/CI/Standard_Test_Interface#Discovery

Activity of the Fedora PR pipeline can be seen here:

• https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-pr-pipeline/activity

This seems not to work at all. The build at https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-pr-pipeline/detail/fedora-rawhide-pr-pipeline/176/pipeline fails on some unrelated issue (was told over IRC that it is "the image failed to boot with eth0"). Is the CI thing ready to be used?

Changing the title to WIP until it's resolved.

[citest]

[citest]

https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-pr-pipeline/detail/fedora-rawhide-pr-pipeline/197/pipeline

https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-pr-pipeline/detail/fedora-rawhide-pr-pipeline/197/pipeline/

it failed, yet I have no idea how to read what happened, the log is horrible.

How can i help to move this forward?

Bump.

Sorry for late reply, just returned after PTO. Unfortunately the log for the job above is gone. The problem within the nvr check should now be fixed. However there seems to be a bug in standard-test-roles :(. I'll rerun the ci job when the ci pipeline is in a good condition.

I'll rerun the ci job when the ci pipeline is in a good condition.

It seem the CI is far from being usable. I understand that not everything always works, but so far I have never seen this working at all. This years Flock gave me the impression that the CI is the next big thing (after modularity), but this seems even more broken than modules.

Is the Ci something that is "production ready" or are we the guinea pigs here? Don't get me wrong, I fine with both, but I'd rather have the expectations sorted.

Thanks for the feedback Miro. I see it's frustrating to run into several issues in a row. Unfortunately this sometimes happens. We are trying hard to make the stuff stable and working however we're still running into various unexpected problems and complications on the way. So while not 100% production ready we are definitely aiming there. Thanks for being patient and helping us as one of the early adopters.

[citest]

The pipeline seems to be fixed now.
Let's do another [citest].

I'm not sure what commit is this on, but I guess we get more reliable results if it is rebased on current master, as there were some recent FTBFS fixes.

Also, require gcc.

OK, let's rebase once more, so I can fast forward merge this and we are good to move down to 3.6...

Fedora CI passed.