Hi there,
On Fri, Jan 7, 2022 at 6:43 PM Vít Ondruch <vondruch(a)redhat.com> wrote:
Hi everybody and sorry for the rant, but I must vent somewhere.
So I am preparing updated Ruby package. I know that there is rpminspect
executed at some point and the results are available in Bodhi [1].
Therefore, I'd like to execute similar test on my machine prior pushing
anything anywhere. So lets give rpminspect a shot:
~~~
$ rpminspect
rpminspect: Please specify a configuration file using '-c' or supply
./rpminspect.yaml
~~~
Hm, bummer. So how is this configured in Bodhi? Lets look at Jenkins [2].
Hm, nice, but how is it executed? No clue.
So lets try the main task [3]. Ha, console [4], there must be the
"rpminspect" command, right? But no, there is non. There is just 11 pages
of nonsense.
So looking once again, ok, kubernetes, there is used some container. Lets
check what the rpminspect-pipeline stands for, opening its repository [5].
FMF, that sounds familiar, lets open the rpminspect.fmf [6]. Hm,
/usr/local/bin/rpminspect_runner.sh, what is that? How can I get it? Ah,
there is image repository and the file [7], which as again more then 5
pages of gibberish. There finally some `rpminspect` call on line 155 [8],
but then I could continue with localization of the config file.
This is really awful and I suffer every time I have to do something like
this. I am really frustrated. I really don't understand, why the command
can't be visible as far as at the console [4].
Comparing e.g. with GH actions, I have opened cpython repository for the
first time in my life and on 5 clicks, I know the test suite is executed
via `make buildbottest TESTOPTS="-j4 -uall,-cpu"`.
Yes, this is how CI usually works. You have some scripts that you want to
execute in some environment and maybe, at the end, you want to
retrieve/archive a few test-specific files/directories that you know were
created during the run. Easy-peasy.
We had trouble with the "environment" part in the past, when OpenStack was
not very reliable. But instead of fixing just that one problem (credit card
would do the trick), we went further and introduced more opinionated
layers. In hindsight, I think we went a little overboard.
Do I want to try to test rpminspect at this moment? No, No, No and no
again, because this is not CI, this is just torture. This is so
intimidating.
So, would it be so big problem to have the several rpminspect calls which
are certainly done somewhere at some point visible on the Jenkins console
[4]?
The problem is that Jenkins is actually not running anything -- it
delegates everything. So maintainers will never find any useful information
in Jenkins logs. Jenkins doesn't really know what rpminspect command will
be executed several layers down. And it currently doesn't have access to
the raw output of the test run, the only thing that is returned back
through all the layers is the captured stdout/stderr from tmt-executed
tests (so we cannot just dump the command to a file in a lower layer and
then print it to the Jenkins console later -- that file wouldn't be
available in Jenkins). The situation will be much better when the whole
workdir is available to the upper layers (Miro shared a JIRA link in the
other email in this thread).
However, you're not completely out of luck here. rpminspect prints the
command that was used to produce the test results as part of its
"diagnostics" inspection [1].
And there you can see:
Details:
/usr/bin/rpminspect -c /usr/share/rpminspect/fedora.yaml --format=json
--release=fc36 --profile=rawhide ruby-3.0.3-154.fc36 ruby-3.0.3-155.fc36
That is the command that actually runs in CI.
Thanks,
Michal
[1]:
https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-...