In openqa/dispatcher, relvalconsumer and check-compose roles, we
install Python libraries from git checkouts (these are things we
don't really want to package as they change too much). This
enhances those roles so that we check whether pip considers the
libraries to be installed, and install them if it doesn't. The
purpose is to catch when the Python version rolls over on system
upgrade, and reinstall the libraries in that case - I got bitten
by this when upgrading to F32, I forgot to reinstall these libs
for Python 3.8, and it broke things for a couple of days before
I noticed and fixed it manually...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I changed how check-compose upstream does email recipient config
to try and fix the 'get Atomic-related emails to Atomic people'
problem again after Fedora-Atomic composes went away. This is
an attempt to adjust the play to populate the config file for
that change. Let's see what blows up!
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This should hopefully avoid an awkward problem I noticed with
'python3 setup.py install' dumping replacements in /usr/local
for packaged scripts (e.g. fedmsg-logger)...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This includes some tweaks to the core fedmsg roles to allow a
'generic' way of indicating that a box should use fedmsg-hub-3
not fedmsg-hub, and make the restart notification work for that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The special configuration for check-compose mails for two-week
Atomic nightly composes was broken due to fedfind changes. We
need to tweak this template a bit as part of fixing it up.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I'm switching the misc. QA fedmsg consumers over to using fedmsg-
hub, due to https://github.com/fedora-infra/fedmsg/issues/365 .
So we need to adjust how we install check-compose, install a
config file to enable the consumer, and also set up the fedmsg
base and hub roles on the openqa server boxes (which do the
check-compose job ATM).
as per the similar recent commit to openqa roles, this is not
needed and breaks stuff (as the checkout is run during 'check'
but the install step isn't, the updated code is never installed)
I just killed the old BOS openqa deployment, which sends out
those 'compose check' emails, so I'm gonna go ahead and have
this new openqa deployment start sending out those emails a
little earlier than planned. This should result in both prod
and staging openqa running a compose check each day, but only
prod should actually send out an email report.