action #88363
closedopenqa-client cannot return job info
Description
lan@localhost:~/work/openqa-job-retrigger-tool> /usr/share/openqa/script/client --host http://openqa.qa2.suse.asia --apibase / group_overview/20 limit_builds=1 undef lan@localhost:~/work/openqa-job-retrigger-tool> /usr/share/openqa/script/client --json-output --host http://openqa.qa2.suse.asia --apikey 81F4ED4794F6E574 --apisecret 3895BC8179CCA96 --apibase / group_overview/20 limit_builds=1 null
openqa-cli api --apibase / --host http://openqa.qa2.suse.asia --pretty group_overview/20 limit_builds=1 { "build_results" : [ { "all_passed" : "", "build" : "124.5", "distris" : { "sle" : 1 }, "escaped_build" : "124_5", "escaped_id" : "15_SP3-124_5", "escaped_version" : "15_SP3", "failed" : 0, "key" : "15-SP3-124.5", "labeled" : 0, "oldest" : "2021-01-14T11:58:38", "passed" : 105, "reviewed" : 1, "skipped" : 15, "softfailed" : 0, "total" : 120, "unfinished" : 0, "version" : "15-SP3" } ], "comments" : [], "description" : null, "group" : { "id" : 20, "is_parent" : null, "name" : "SLE-15-SP3-Performance", "rendered_description" : null }, "max_jobs" : 120, "pinned_comments" : [] }
Updated by lansuse about 3 years ago
openqa-client return null, but openqa-cli works
Updated by okurz about 3 years ago
- Project changed from openQA Tests to openQA Project
- Category set to Support
- Status changed from New to Feedback
- Assignee set to okurz
- Target version set to Ready
lansuse wrote:
`lan@localhost:~/work/openqa-job-retrigger-tool> /usr/share/openqa/script/client --host http://openqa.qa2.suse.asia --apibase / group_overview/20 limit_builds=1 undef lan@localhost:~/work/openqa-job-retrigger-tool> /usr/share/openqa/script/client --json-output --host http://openqa.qa2.suse.asia --apikey 81F4ED4794F6E574 --apisecret 3895BC8179CCA96
the host "openqa.qa2.suse.asia" is not publically reachable but I still suggest as a best practice to treat "apikey" and "apisecret" like your passwords and not post them in chat rooms or tickets or wiki pages.
The command line looks garbled. I assume the word "undef" should go into its own line and is the output you got? Can you try the command openqa-client --host http://openqa.qa2.suse.asia group_overview/20 get limit_builds=1 please?
Updated by okurz about 3 years ago
- Due date set to 2021-02-24
- Priority changed from Normal to Low
no response, giving more time.
@lansuse please see my above question
Updated by lansuse about 3 years ago
okurz wrote:
no response, giving more time.
@lansuse please see my above question
- apikey is no effect for http://openqa.qa2.suse.asia/ for now, and I will pay much attention to it from now on.
- I tried
openqa-client --host http://openqa.qa2.suse.asia group_overview/20 get limit_builds=1but no any output.
Updated by okurz about 3 years ago
- Due date changed from 2021-02-24 to 2021-02-19
Ok. So what you are doing with the parameter --apibase / is basically not using the intended web API at all but instead retrieve the web pages that are meant for consumption by browsers and human readers. If you want to have a machine readable representation of the "group overview" page in JSON format you can use for example
curl -s https://openqa.opensuse.org/group_overview/1.json
Both openqa-client and openqa-cli are not meant and not necessary to access these pages. Good enough?
Updated by lansuse about 3 years ago
https://gitlab.suse.de/lansuse/openqa-job-retrigger-tool
This is a tool to monitor the openqa jobs and retrigger those failure ones. It use openqa-client to retrieve group status. This method not works in last openqa, so I guess maybe some update involve the problem.
But I found a workaround, openqa-cli api --apibase / --host http://openqa.qa2.suse.asia --pretty group_overview/20 limit_builds=1
Updated by okurz about 3 years ago
- Status changed from Feedback to Resolved
Interesting. I do not know what are the conditions that make openqa-job-retrigger-tool consider candidates to retrigger. Have you looked into "auto-review" as documented on http://open.qa/docs/#_enable_custom_hook_scripts_on_job_done_based_on_result and presented over multiple channels (SUSE QE Tools workshop, one.suse.com, opensuse-factory@opensuse.org mailing list post, etc.). I think it can help you in a more consistent and maintainable way. Your workaround might work for the time being but keep in mind that only the routes on /api/v1 should be considered stable, the other routes can change with updates again.