Example hook script #249
Example hook script #249
Conversation
…generated * Allow adding a hook script to particular sub folders * Allow adding a generic hook script that is run for all projects * See https://progress.opensuse.org/issues/161879
| # run additional hook script from current subfolder | ||
| [[ -x "$subfolder/hook_script" ]] && "$subfolder/hook_script" 2>$logdir/hook_script.err > $logdir/hook_script.out | ||
|
|
||
| # run additional hook script from script folder | ||
| [[ -x "$DIR/generic_hook" ]] && "$DIR/generic_hook" "$environ" 2>$logdir/generic_hook.err > $logdir/generic_hook.out | ||
|
|
There was a problem hiding this comment.
this looks like it would be what we need but to have that mergeable the example script above shouldn't be commited directly. Instead you could put it into a documentation in the README of this project.
There was a problem hiding this comment.
Yes, this is just a draft to show what it would look like for real.
There was a problem hiding this comment.
I would consider 106 lines way too much for an inline code snippet.
There was a problem hiding this comment.
@kalikiana not script/rsync.sh which is not a hook script but script/generic_hook which is 9 lines
| @@ -79,6 +79,12 @@ set +e | |||
| [ ! -L "$subfolder/.run_last" ] || rm "$subfolder/.run_last" | |||
| ln -s -T "$(pwd)/$logdir" $subfolder/.run_last | |||
|
|
|||
| # run additional hook script from current subfolder | |||
| [[ -x "$subfolder/hook_script" ]] && "$subfolder/hook_script" 2>$logdir/hook_script.err > $logdir/hook_script.out | |||
There was a problem hiding this comment.
Can the hook_script have any effect on the command line that is generated and executed afterwards? How about to allow to export variables in the hook script which are read if defined by the later scripts to be able to customize the generated isos sync command(s)?
There was a problem hiding this comment.
I think the established pattern here is that scripts generate certain output and those files and then be consumed later on. So I would just have the hook script generated e.g. a file with scenario definitions and then maybe also directly the openqa.cmd file with the openqa-cli commands that will be invoked later by rsync.sh.
Not sure how it would work with environment variables. We cannot just source the hook script because it might also be e.g. a Python script.
There was a problem hiding this comment.
think that a JSON data structure would be the lingua franca for hooks to exchange information. Following up on that, the solution may go in a different direction.
Note that the consumer of the hook script output is also just a script (print_openqa.sh if present; otherwise rsync.sh will just invoke openqa.cmd if present). So probably it makes most sense to simply generate the required openqa-cli commands and write them to openqa.cmd and skip having print_openqa.sh.
It is really not like there's some subsequent logic in openQA that would be able to consume a JSON file. There's just the generation of openqa-cli commands within this trigger repo itself and so far this is just a generated shell script.
The reason I mention YAML is because you most likely want to make use of openQA scenario definitions - but those are defined via YAML and not JSON.
I'm happy to chat and brainstorm in the office or during a call
We'll probably have a chance to talk in the office as of the 24th.
See particular commit messages and https://progress.opensuse.org/issues/161879