#6383: Build a 'test' compose automatically when installer-related
packages change
by Fedora Release Engineering
#6383: Build a 'test' compose automatically when installer-related packages change
----------------------+------------------------
Reporter: adamwill | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: other
Keywords: | Blocked By:
Blocking: |
----------------------+------------------------
We have a kind of 'chicken and egg' problem with anaconda updates on
Branched after Bodhi activation. We can't test them until we have a
compose built with them included, but as things stand, the only way we can
get a compose with them included is to push the update stable blind so it
goes into nightly composes, or go through the manual 'candidate' /
'production' compose request process.
It would be a lot more awesome if we had a nice smooth automated flow
here. What I'd like to see on releng side is that when an update
containing any installer-related package appears (I'm not sure where we'd
want to store the list of packages that should trigger this process, or
whose job it should be to maintain it), a 'test' compose is produced
entirely automatically which contains that update (the packages from the
update would be tagged into some special tag and the compose built from
that, most likely).
That's a 'test' compose in the Pungi / productmd meaning of the word -
Pungi 4 has three compose types, 'nightly', 'production' and 'test', and
we haven't used 'test' for anything yet. This seems like a good fit.
The rest of the chain would be to run openQA tests on the 'test' compose
and then get the results into Bodhi (ideally in such a way that we could
automate the stable push, or at least block stable push of completely
broken updates), but that's mostly not rel-eng's problem. The only bit
that might conceivably involve releng is the question of how we get the
results to the right update - it's easy to trigger openQA tests for any
new compose that appears, but it's a more interesting problem to know that
the results from testing 'Fedora-24-20160401.t.0' or whatever should go to
the Bodhi update for 'anaconda-24.14-1.fc24' or whatever.
I don't know the best way to do that yet - not sure whether it would make
most sense for the thing that builds the test compose to simply log what
updates it contains somewhere that can be queried later by the thing that
submits the results, or whether the thing that submits the results should
have to figure it out somehow from the test compose metadata. Open to
ideas there.
If this works out, we could of course potentially extend the mechanism for
testing other things it makes sense to test at the level of an entire
distribution compose, like maybe new kernels and bootloaders and stuff.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6383>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
