Removing the topic_prefix from fedora messaging config files was a bit
premature. So let's put them back in place.
Signed-off-by: Michal Konecny <mkonecny@redhat.com>
The kiwi_build test for containers has been around long enough
that we can require it now. Also, drop live_build requirement
for Workstation because we're going to flip openQA to using Kiwi
to build the Workstation live (just as releng has for the
official one). This doesn't risk allowing broken updates through
as we still require the install_default_update_live tests to
pass, and they can't pass if the image build fails.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Well, I hope, anyway. This is a nightmare to predict/test because
jinja is weird and ansible puts it in a weird non-standard mode.
But this does the same thing as the product_versions macro we
use for all other releases - just leave out all attempts to avoid
blank lines.
It *might* cause blank lines in some states, but I *think* I found
(while testing product_versions) that blank lines don't break the
parsing. I can't find anywhere in the YAML spec where it actually
defines when a block sequence *ends*, but as a matter of fact it
seems like whatever parser is being used here doesn't choke on
blank lines.
My ideal goal here is that, whatever entries are present or
absent based on the conditionals, we get a clean block sequence
with each entry on its own line and no blank lines, but this
seems to be *incredibly* hard to get jinja to do.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It's renamed to kiwi_build, but we can't gate on the new name
yet as not all updates will have it. We'll have to wait for a
while.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It's named differently now (kiwi_build, not live_build). We don't
really need the build test in the gating config anyway as the
other two tests depend on it. We could add kiwi_build back in a
few months if we really want to, though.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This uses the release number templates for the product_versions
blocks in the gating config, instead of hardcoding them. I tried
to include some flexibility so we can easily manually flip gating
on or off for Rawhide or Branched - for specific rules, or the
whole file - around branch time, if we need to (sometimes we do,
as we can get in catch-22 situations and stuff during branching).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We added tests of container building and a subset of container
and server tests on aarch64 a couple of months back. These have
now been running long enough it should be safe to add them to
the gating config (all pending updates should have had these
tests run against them if appropriate).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
they cannot work until the first branched compose is done and
mirrormanager is pointing somewhere for f41.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
That way we don't have to keep updating this file when cutting GA. In
the period where there is no branched release, `{{FedoraCycleNumber+1}}`
conceptually refers to rawhide, though that's more properly covered by
the explicit `fedora-rawhide` version. But at least I don't think it
should do any harm.
Follow-up to 793349a98d ("greenwave: stop gating f39 updates for
CoreOS"), which has more context.
Many of the packages currently gated by the CoreOS tests are also used
outside of the CoreOS artifacts. And so it happens that e.g. Bodhi
updates are opened for releases that CoreOS itself no longer uses.
However, since those releases aren't monitored by CoreOS anymore, no
CoreOS tests run. In that case, we shouldn't be gating updates on those
releases.
Fedora 39 is in this scenario right now. Ideally, we could use symbolic
names here instead like `fedora-latest-stable` or something. For now,
I'll add this to a rebase checklist we have to make sure we update this
list shortly after a GA release.
We had to leave these requirements out while the openQA move to
testing on UEFI by default was in flight. Now it's been done for
several weeks, all pending updates ought to have these results,
so it should be safe to turn these on again.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This was wrong and I'm surprised we never noticed till now. We
don't schedule these tests on critical-path-standard so we should
not gate on them. The alternative fix is to keep gating and start
testing, but the only thing that's actually in c-p-standard is
fprintd-pam and we don't pull fprintd stuff into containers, so
there's no sense testing it, really.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We're landing a big change to make openQA tests UEFI-by-default,
with BIOS as an occasional variant (exact opposite to the current
setup). This adjusts the gating policies appropriately. We have
to temporarily disable gating for a few tests, due to the fact
that there will be 'in-flight' updates which do not have a result
for the 'bios' scenario (they have results for 'uefi' and '64bit',
with '64bit' being a BIOS result; post-switchover, updates will
have a result for '64bit' and 'bios', with '64bit' being a UEFI
result). I will re-enable this in about a month and clean up any
stragglers somehow.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Also drop F37 from the version lists (it's EOL) and, er, enable
gating on the desktop_backgrounds tests for F39 (whoops, forgot
to do that...a long time ago).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The subject type is `bodhi_update`, not `koji_build` since we're
reporting against an update, not koji builds. Also adjust the id
accordingly.
Add `fedora-41` now that we've branched.
Fixes 0f91c69c5c ("greenwave: gate CoreOS packages on
`coreos.cosa.build-and-test`").
Add the contexts to the null policy as a reference and to be nice,
and then add the actual policy for gating CoreOS packages on the
`coreos.cosa.build-and-test` testcase.
See also: https://github.com/coreos/fedora-coreos-tracker/issues/1617
As F38 is now the oldest stable release, we should not require
the update tests for F38 updates.
This *really* needs to happen automatically somehow, sigh.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
These have been running stably for some time now, so it should
be OK to gate on them. I have checked through old stuck updates
and unblocked any that would be gated on this, remaining ones
aren't gated on the server tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We don't have new F39 backgrounds yet, so this test will always
fail. Let's split the test into its own policy so we can easily
control whether we're gating on it (this will be useful for
future cycles, probably).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
F39 updates can't pass testing fully till we have a new compose
and can build new non-Rawhide base images, but we need some
updates that are currently pending to go in the compose. It's
a catch-22, just disabling gating till this is sorted seems
like the least worst option.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Drop most fedora-36 entries, and don't require upgrade tests on
F37 any more as it is now the oldest stable.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We're moving most tests out of universal and into Server-dvd-iso.
See os-autoinst-distri-fedora and fedora_openqa commits for more
details on this.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We're not ready to turn gating on for F38 yet, we need a decent
compose and the tests to settle down first.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
