-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add GitHub action for cloning an openQA job mentioned in a PR description #292
Conversation
openqa-clone-and-monitor-job-from-pr
Outdated
} | ||
|
||
sub _run_cmd ($name, $args, $capture_output = 0) { | ||
my $res = $capture_output ? `$name $args` : system "$name $args"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probable make sure that the arguments cannot be used to run arbitrary commands, not sure if this would be possible with the current inputs. But better be safe than sorry.
If this is used for pull_request_target, it could be possible to leak our API credentials.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we are in perl already, instead of calling openqa-cli ...
we might also directly use
use OpenQA::CLI;
my $ret = OpenQA::CLI->new->run(@args);
Just that we need to capture stdout. OpenQA::CLI could also offer an option for returning the output in a variable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could but we needed to add OpenQA::
to the search path. And we needed to make sure not to break the API in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm, now I'm wondering why the openQA modules aren't installed in the usual place for perl modules, where it would be found by default.
I understand that for the os-autoinst modules that could be a bad idea, but OpenQA is a clear namespace.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
open(my $fh, "-|", $cmd, @args);
while (<$fh>) { ... }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And to clarify what I meant and what we discussed in the call: If a user manages to manipulate any of the input variables to contain anything then the secrets can be leaked: '; curl-command-to-post-secrets-to-some-server; '
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I now changed it to use system
when we don't want to capture the output and open
when we want to.
In my tests arguments are passed literally with both commands when at least one argument is given (which is always the case here). So that should address the security concern.
Note that I've also tested the error handling and especially checking the command's exit code really works after the close
call (when previously invoking the command via open
). So if openqa-clone-job
can be started but fails with a non-zero exit status we get the right error message and the code doesn't try to parse the output as JSON (leading to a worse/confusing error message).
openqa-clone-and-monitor-job-from-pr
Outdated
_run_cmd 'openqa-cli', 'monitor', '--host', $expected_url, @secrets, @job_ids; | ||
} | ||
|
||
$ENV{TEST_MODE} ? 1 : run; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could save the TEST_MODE thing and do:
$ENV{TEST_MODE} ? 1 : run; | |
run() unless caller(); |
openqa-clone-and-monitor-job-from-pr
Outdated
my $expected_url = $ENV{OPENQA_HOST} // 'https://openqa.opensuse.org'; | ||
my $group_id = $ENV{OPENQA_SCHEDULE_GROUP_ID} // 118; | ||
my $pr_body = $ENV{GH_PR_BODY} or die 'GH_PR_BODY must be set'; | ||
my $gh_repo = $ENV{GH_REPO} or die 'GH_REPO must be set'; | ||
my $gh_ref = $ENV{GH_REF} or die 'GH_REF must be set'; | ||
my $gh_srv = $ENV{GITHUB_SERVER_URL} or die 'GITHUB_SERVER_URL must be set'; | ||
my $api_key = $ENV{OPENQA_API_KEY} or die 'OPENQA_API_KEY must be set'; | ||
my $api_secret = $ENV{OPENQA_API_SECRET} or die 'OPENQA_API_SECRET must be set'; | ||
my @secrets = ('--apikey', $api_key, '--apisecret', $api_secret); | ||
my @vars = ("BUILD=$gh_repo.git#$gh_ref", "_GROUP_ID=$group_id", "CASEDIR=$gh_srv/$gh_repo.git#$gh_ref"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assume that somebody will run this as a script, please add at least POD documentation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really except for manual testing. It is supposed to be used via a GitHub action. But I'll create POD documentation nevertheless.
openqa-clone-and-monitor-job-from-pr
Outdated
# Note that this script is intended for execution via the GitHub action defined in | ||
# actions/clone-job/action.yaml. | ||
|
||
package openqa_clone_and_monitor_job_from_pr; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not needed, as this is a script. An idea on a separate level, why not make it an openQA cli command instead of a wrapper for it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An idea on a separate level, why not make it an openQA cli command instead of a wrapper for it?
obviously, out of the scope of this PR i'd say
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is needed for testing and will not harm otherwise.
why not make it an openQA cli command instead of a wrapper for it?
This is also invoking the clone script. Additionally, it contains GitHub-specific parts; its usage is tailored for use within a GitHub action (taking "arguments" mainly from environment variables) which doesn't really fit into openqa-cli
's style.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, and the openQA repo is already big enough. So I really like to add code that is rather specific to this additional scripts repo (like we did with many of the other scripts contained here). But that also means I cannot really utilize the modules from the openQA repo. Even if the modules would be installed in the normal Perl path (or we adjusted the search path) this would be problematic because when someone would change things on the openQA-side it might break things here (and openQA is not really developed as an API-stable Perl module).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even if the modules would be installed in the normal Perl path (or we adjusted the search path) this would be problematic because when someone would change things on the openQA-side it might break things here (and openQA is not really developed as an API-stable Perl module).
I'm looking more into proper github action repo as a separate thing, but that is something far in the future :)
the scope of openqa-cli's argument makes a lot of sense
af60f9c
to
7531867
Compare
print 'No test cloned; the PR description does not contain '; # uncoverable statement | ||
print "a command like '\@openqa: Clone $expected_url/tests/<JOB_ID>'.\n"; # uncoverable statement |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will this be shown in the UI? as a comment on the GH pull request?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So far it'll be only shown in the log of the GitHub action. We could extend it later to also write a comment or use the statuses API.
openqa-clone-and-monitor-job-from-pr
Outdated
For local testing you may also invoke the script manually. Have a look at the | ||
handling of environment variables at the beginning of the script code as you | ||
need to set certain additional environment variables that are normally supplied |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For local testing you may also invoke the script manually. Have a look at the | |
handling of environment variables at the beginning of the script code as you | |
need to set certain additional environment variables that are normally supplied | |
For local testing you may also invoke the script manually. Have a look at the | |
handling of environment variables at the beginning of the script code as you | |
need to set certain additional environment variables, the `test/05-clone-and-monitor.t` | |
can also clarify this script's behavior from user perspective. |
Since this is only meant for GH, I think it's ok to redirect the reader to how the test is done.
…tion This GitHub action allows to clone a job when creating a PR by mentioning it in the PR description via `@openqa: Clone https://…`. Related ticket: https://progress.opensuse.org/issues/130934
Marking as ready again as I was able to test it and it works. Of course I only tested it so far on my fork but I guess that should suffice for now (see Martchus/os-autoinst-distri-opensuse#2 for an example; I cancelled the cloned job manually). Later (or next week) I'll provide a PR to use it in the openSUSE distribution. In addition to that, I suppose it would also make sense to treat
Or was there a reason why we even treat the hostname as a secret? |
This GitHub action allows to clone a job when creating a PR by mentioning it in the PR description via
@openqa: Clone https://…
.Related ticket: https://progress.opensuse.org/issues/130934