As we're working more with the test invocation spec [1] and the
ansible implementation [2], there are a few things which aren't 100%
clear to me and I'm hoping to get some clarification on.
Why is "ansible_connection=local" a requirement for the testing system?
Why is obtaining the test subject solely the responsibility of the
testing system? This seems like something that could potentially have
different requirements for different usecases. For example, something
like abicheck needs to grab previous builds in addition to the latest
build of a given package.
I don't understand what we're trying to accomplish with all the
test_<subject>.yml. Is the idea that we'd run test_oci.yml for every
package used in building a container against that container?
What is the point in having test_local.yml and test_rpm.yml? I remember
the idea of in-situ tests being part of the discussion but I thought
that we were pretty limited on what we could do with those since we're
not going to be modifying rpm like debian was able to get changes made
for .deb packages.
Thanks,
Tim
[1] https://fedoraproject.org/wiki/Changes/InvokingTests
[2] https://fedoraproject.org/wiki/Changes/InvokingTestsAnsible
Hi Tim,
When I try to send a pull request in upstreamfirst, it happened to
return a fatal error. So I filed a ticket.
However I don't know how to add subscriber in the ticket, so just send
you this email as well as copy to the CI list.
https://pagure.io/fedora-infrastructure/issue/6083
HTH.
--
Ziqian SUN (Zamir)
zsun(a)fedoraproject.org
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
Want to know more about Fedora?
Visit https://fedoraproject.org/wiki/
Hi there,
My name is Barak, and I've been with the oVirt CI team for a couple of
years now.
Looking as the past threads in this mailing list and the linked
proposal documents, it seems that we are facing some very similar
challenges.
I'm hoping we can find some fertile ground for collaboration here.
I would love to join the discussion here and offer some of the things
we've learned working on oVirt's CI system and the solutions we came
up with. I'm sure there will also be things to be learned here to take
back to oVirt's CI system.
Looking forward to some interesting discussions,
Barak.
--
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted