Dne 10. 01. 22 v 10:30 Michal Srb napsal(a):
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
Oh, wow. Please, can this be extracted somewhere visible? Nice place
would be right bellow the "Test Result : tests" in the main landing
page. Actually, I would not mind to have the whole "diagnostics" section
visible on the first sight.
Also, having no real experiences with rpminspect, I might just guess
that diagnostics might be the first section reported by rpminspect, so
I'd suggest against alphabetical sorting of the results.
Vít