frontend, backend, cli, rpmbuild, python: optionally run fedora-review after build
See RHBZ 1526396
I implementing a possibility to opt-in for running `fedora-review`
after every build in a project. At this moment, we have only per
project setting, but in the future we probably should increase the
granularity (per package, per build).
Failing to run `fedora-review` tool or the build results not passing
all `fedora-review` checks doesn't affect the build status in any
way, i.e. successful build won't fail because of failed
To be sure, that this feature works as expected, I added a new beaker
test called `runtest-fedora-review.sh`.
I tried to not over-engineer the design on the frontend side and
simply add support for `fedora-review` instead of a general support
for hooking (static) analysis tools with `fedora-review` as the first
supported tool. We should IMHO gradually add support for new tools and
once some additional abstraction is usefull, implement it.
At this moment, there are two inconveniences regarding `fedora-review`
1) It doesn't work with Mock Tmpfs plugin enabled, and it doesn't
propagate `--mock-options` to all mock calls, therefore it cannot
be workarounded by `--mock-options='--disable-plugin=tmpfs'`.
Please see https://pagure.io/FedoraReview/pull-request/409
We need to wait until the PR gets merged and released, or use our
custom build. This doesn't affect us though, because we use a
custom mock config and set all the options there.
2) There is no option for specifying output directory, it gets
generated from the package name. Which is not optimal for our
use-case because nobody would expect that a `foo` directory is
`fedora-review` output. As a workaround, I am renaming the output
directory after `fedora-review` finishes. Please see
It's worth noting that we cannot archvie configs as soon as we did
before because this way, they would be already archived when we want
to call fedora-review, and therefore the generated config would not be
available. We need to archvie them later.