#6383: Build a 'test' compose automatically when installer-related packages
change
-----------------------+-----------------------
Reporter: adamwill | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: other
Resolution: | Keywords:
Blocked By: | Blocking:
-----------------------+-----------------------
Comment (by adamwill):
Replying to [comment:5 atodorov]:
Hi Adam,
what you propose is what RHEL QE has been working on as well. We have
infrastructure (Jenkins) to trigger tests on new package builds or new
compose builds but these tests are only kickstart based. OTOH I've been
revamping anaconda's tests/gui/ and the PR got accepted yesterday so I
will be looking into writing some more tests. WARNING: Somebody else from
my team is working on a completely different GUI automation solution which
I don't agree with but that's another story.
It looks like we have a fair amount of overlap between the 3 teams (RTT
trying to
be closer to anaconda devel) and I'd like to plan ahead wrt
external Fedora builds/testing and internal RHEL builds/testing. I feel
like we've been trying to reinvent the wheel in the last 6 months.
Let's get together and talk!
Well, add another to your list of automated GUI test systems =)
[
https://openqa.fedoraproject.org openQA] is in production for Fedora and
has been for a while, and we already have quite a lot of process
integration in place; openQA tests are automatically run for Branched and
Rawhide nightly composes and 'candidate' composes (the Pungi 4 equivalent
of TCs and RCs), and email notification of results is sent to mailing
lists. We currently use a single-purpose fedmsg consumer for triggering
the openQA tests, turning that into a Taskotron task is on the todo list
(though the standalone consumer approach actually works perfectly well).
The bits of my proposal that would involve the most new work are, I think,
doing the actual compose, and mapping the results back to Bodhi. Running
tests from a new compose is something we do already, getting the tests run
for 'test' composes would be about two minutes of work. The obvious
question is "how do we build a thing that produces images for testing in
response to Bodhi updates with specific properties appearing?" There are
lots of sub-questions there, of course: do we use Pungi or not? Do we want
to use Taskotron? How much benefit is there to trying to 'harmonize' with
RHEL, given that we use different update systems (Bodhi vs. errata) and
different message queue thingies (fedmsg vs...whatever RHEL uses?) I don't
really have answers to any of those immediately.
--
Ticket URL: <
https://fedorahosted.org/rel-eng/ticket/6383#comment:10>
Fedora Release Engineering <
http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project