QA » openQA Project

We discussed this at the workshop. The actually identified 3 places where we could invoke the hook script:

1. rsync.sh as my previous PR has already shown.
2. Inside the server-side scheduling logic of openQA. It could take another special parameter HOOKSCRIPT=… and run that script server-side.
3. By openqa-cli which could take another parameter --hook-script and would call this script with all test variables specified on the command-line. The script can then amend this list of test variables before openqa-cli makes the actual API request.

Option 3. sounded the most promising.

talk to Santi yesterday and from my understanding what he is looking for seeing at the moment is just that running the openqa-trigger-from-obs's script will just go through a set of other (hook) scripts which will expand the output (openqa-cli). Having said that, no condition are given for when the hook will apply. He thinks of this functionality behaving similar to git-hooks.

mkittler wrote in #note-3:

We discussed this at the workshop. The actually identified 3 places where we could invoke the hook script:

1. rsync.sh as my previous PR has already shown.
2. Inside the server-side scheduling logic of openQA. It could take another special parameter HOOKSCRIPT=… and run that script server-side.
3. By openqa-cli which could take another parameter --hook-script and would call this script with all test variables specified on the command-line. The script can then amend this list of test variables before openqa-cli makes the actual API request.

Option 3. sounded the most promising.

option 3 sounds nice.

• while/when working on the implementation: remember you can always ask me

It would be good to propose a PR with the --hook-script as mentioned in jitsi and either ask for feedback in Slack or conduct a pair programming session as suggested

What I tried today:

there is -D option in openqa-cli (activated with -f)
for example perl -I lib script/openqa-cli api -f -D ../hook/twdata.json --pretty --host http://127.0.0.1:9526 -X POST isos
where hook/twdata.json looks like

{                                                       
    "ARCH":"x86_64",                                                       
    "BACKEND":"qemu",                                                       
    "BUILD":"newtw",
    "DISTRI":"opensuse",
    "FLAVOR":"NET",                                                       
    "VERSION":"Tumbleweed",                                                       
    "ISO":"openSUSE-Tumbleweed-NET-x86_64-Snapshot20240709-Media.iso",                                                       
    "USBBOOT":"3"
}

I was thinking to extend lib/OpenQA/CLI/api.pm with --hook-scripts which when it is set it will leverage this option + take data from args to trigger custom jobs.

I didnt manage to implement anything so far.
Very likely, @szarate will have time tomorrow for a pair session.

RFC https://github.com/os-autoinst/openQA/pull/5757

Today at the programming session with @szarate we defined the interface and tested the idea.

The idea¶

Original call:¶

openqa-cli api --post-script-hook hook/awesome_scripts_set --host http://127.0.0.1:9526 -X POST isos BETA=1

Script post_foobar is called| it removed BETA=1¶

openqa-cli api --post-script-hook hook/awesome_scripts_set --host http://127.0.0.1:9526 -X POST isos FOO=BAR

Script post_hello_world is called | it added HELLO=WORLD¶

openqa-cli api --post-script-hook hook/awesome_scripts_set --host http://127.0.0.1:9526 -X POST isos FOO=BAR HELLO=WORLD

Invoke all together. Should be also possible¶

openqa-cli api --post-script-hook hook/awesome_scripts_set -f -D data.json --host http://127.0.0.1:9526 -X POST isos HELLO=WORLD

The interface¶

the openqa_cli can take two additional parameters. One will enable scripts to run before the data format and the second after.
The scripts can be separated per folders, which will contain both sorts of scripts, and which they will be distiguished by a prefix.
examples:

/hook/<awesome_scripts_set>/
  - pre_<script_name>
  - post_<another_or_the_same_name>

So the interface will define:
--pre-script-hook <path_to/awesome_scripts_set>
--post-script-hook <path_to/awesome_scripts_set>

I moved on with the code which is tested for a hello_world script. Despite this ticket is not for the full implementation I think, what we have so far It is enough to move one with the idea. I still have to push the changes but I got a bit obsessed with some ideas.

AC status¶

AC1: We know what we need to change in our current mechanism for triggering tests in the light of #159828.
I think it is more clear now.
We agree with Santi to move on with the changes on openqa_cli and then continue with the integration of the result on openqa-trigger-from-obs.

AC2: We know who (which team) is going to change what parts.
So we have three main tasks:

• openqa_cli is on qatools
• openqa-trigger-from-obs is likely possible to be done by qatools
• scripts by core-team. But I think that there need a template which is something which both teams can collaborate and provide.

Actually this last is what I am experiment with atm.
I will push/update PR asap

ybonatakis wrote in #note-11:

Today at the programming session with @szarate we defined the interface and tested the idea.

The idea¶

Original call:¶

openqa-cli api --post-script-hook hook/awesome_scripts_set --host http://127.0.0.1:9526 -X POST isos BETA=1

Script post_foobar is called| it removed BETA=1¶

openqa-cli api --post-script-hook hook/awesome_scripts_set --host http://127.0.0.1:9526 -X POST isos FOO=BAR

Script post_hello_world is called | it added HELLO=WORLD¶

openqa-cli api --post-script-hook hook/awesome_scripts_set --host http://127.0.0.1:9526 -X POST isos FOO=BAR HELLO=WORLD

Invoke all together. Should be also possible¶

openqa-cli api --post-script-hook hook/awesome_scripts_set -f -D data.json --host http://127.0.0.1:9526 -X POST isos HELLO=WORLD

The interface¶

the openqa_cli can take two additional parameters. One will enable scripts to run before the data format and the second after.
The scripts can be separated per folders, which will contain both sorts of scripts, and which they will be distiguished by a prefix.

What do you mean "run before the data format"?

examples:

/hook/<awesome_scripts_set>/
  - pre_<script_name>
  - post_<another_or_the_same_name>

So the interface will define:
--pre-script-hook <path_to/awesome_scripts_set>
--post-script-hook <path_to/awesome_scripts_set>

I moved on with the code which is tested for a hello_world script. Despite this ticket is not for the full implementation I think, what we have so far It is enough to move one with the idea. I still have to push the changes but I got a bit obsessed with some ideas.

And what do the hook scripts offer what can not be done by test variables passed in the same invocation?

AC status¶

AC1: We know what we need to change in our current mechanism for triggering tests in the light of #159828.
I think it is more clear now.
We agree with Santi to move on with the changes on openqa_cli and then continue with the integration of the result on openqa-trigger-from-obs.

The relevant question I have here is how the hook scripts would be discovered from openqa-trigger-from-obs?

AC2: We know who (which team) is going to change what parts.
So we have three main tasks:

• openqa_cli is on qatools
• openqa-trigger-from-obs is likely possible to be done by qatools

What is "qatools"? I guess you mean "SUSE QE Tools"? Assuming that following on I wonder what do you mean with "openqa-trigger-from-obs is […] to be done by [SUSE QE Tools]"?

• scripts by core-team. But I think that there need a template which is something which both teams can collaborate and provide.

With scripts do you mean "openqa-cli hook scripts"? If yes then the idea would be that they live in "openqa-trigger-from-obs"

1. By openqa-cli which could take another parameter --hook-script and would call this script with all test variables specified on the command-line. The script can then amend this list of test variables before openqa-cli makes the actual API request.

Discussed this briefly on Jitsi. So apparently https://github.com/os-autoinst/openQA/pull/5757 implements this proposal.

An open question is how that would be used in production. So please provide a pull request showing how to use this.