Differential D705

use new 'iterate_jobs' function for wiki result reporting
ClosedPublic
Actions

Authored by adamwill on Dec 22 2015, 6:57 PM.

Details

Reviewers
garretraziel
jskladan
Commits
rOPENQAcd9995366714: use new 'iterate_jobs' function for wiki result reporting
Summary

This uses the new generator function in openQA-python-client
for reporting results to the wiki. The main advantage is that
we'll report results to the wiki as each openQA test completes,
instead of reporting all results in a lump after every test
has completed. It's also somewhat simpler, as iterate_jobs can
operate on job_ids or build. Note for review: report_results
doesn't return anything, so the use of a return statement was
unnecessary, that's why I dropped it.

We may, at this point, want to switch back to reporting by ID
in 'compose' and 'current', but I think I'd at least want to
add a method to openQA-python-client for checking if jobs have
been cloned before doing that (so if we create jobs 1, 2 and
3, then job 3 is restarted for some reason as job 4, we would
report results from 1, 2 and 4).

Test Plan

Try out all the paths through report resulting and
make sure they all still work as expected, make sure results
are submitted as they arrive, rather than after all jobs are
complete.

Diff Detail

Repository
rOPENQA fedora_openqa
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
adamwill retitled this revision from to use new 'iterate_jobs' function for wiki result reporting.Dec 22 2015, 6:57 PM
adamwill updated this object.
adamwill edited the test plan for this revision. (Show Details)
adamwill added reviewers: jskladan, garretraziel.
garretraziel accepted this revision.Dec 23 2015, 7:40 AM

Other that what my comment says, looks OK.

fedora_openqa_schedule/report.py
143–144

I don't think that it's necessary to instantiate generator like that, I believe that you can do:

for joblist in client.iterate_jobs(jobs=job_ids, build=build, waittime=waittime):

but nvm.

This revision is now accepted and ready to land.Dec 23 2015, 7:40 AM
adamwill added inline comments.Dec 23 2015, 7:55 AM
fedora_openqa_schedule/report.py
143–144

oh, yeah - it's actually that way because at first I had two different iterate_jobs() calls for job_ids and build, then realized I could just use one and it'd work with whichever was set, but didn't notice it could then be optimized one step further :) I'll clean it up for commit.

Closed by commit rOPENQAcd9995366714: use new 'iterate_jobs' function for wiki result reporting (authored by adamwill). · Explain WhyDec 23 2015, 3:42 PM
This revision was automatically updated to reflect the committed changes.

Revision Contents

PathPackages
Mfedora_openqa_schedule/report.py (15 lines)

Diff 1822

View Options

fedora_openqa_schedule/report.py

Show First 20 Lines • Show All 113 Lines • ▼ Show 20 Line(s)113 result = ResTuple(
114 testtype=uniqueres['type'], release=release, milestone=milestone, 114​ testtype=uniqueres['type'], release=release, milestone=milestone,
115 compose=compose, testcase=testcase, section=uniqueres.get('section'), 115​ compose=compose, testcase=testcase, section=uniqueres.get('section'),
116 testname=uniqueres.get('name', ''), env=uniqueres.get('env', ''), 116​ testname=uniqueres.get('name', ''), env=uniqueres.get('env', ''),
117 status='pass', bot=True) 117​ status='pass', bot=True)
118 passed_testcases.add(result) 118​ passed_testcases.add(result)
119 119​
120 return sorted(list(passed_testcases), key=attrgetter('testcase')) 120​ return sorted(list(passed_testcases), key=attrgetter('testcase'))
121 121​
122 ​
123def wait_and_report(job_ids=None, build=None, wiki=None, report=None, waittime=None): 122​def wait_and_report(job_ids=None, build=None, wiki=None, report=None, waittime=None):
124 """Find some openQA jobs and report the results to Wikitcms (via 123​ """Find some openQA jobs and report the results to Wikitcms (via
125 report_results). Either job_ids (an iterable of IDs) or build (an 124​ report_results). Either job_ids (an iterable of IDs) or build (an
126 openQA BUILD string) is required. wiki and report are passed to 125​ openQA BUILD string) is required. wiki and report are passed to
127 report_results and documented there. waittime (int) is how long to 126​ report_results and documented there. waittime (int) is how long to
128 wait for jobs to complete before giving up; if 'build' is used, 127​ wait for jobs to complete before giving up; if 'build' is used,
129 will also wait for jobs to appear. If jobs are not present and 128​ will also wait for jobs to appear. If jobs are not present and
130 complete when waittime expires, 129​ complete when waittime expires,
131 openqa_client.exceptions.WaitException will be raised. If waittime 130​ openqa_client.exceptions.WaitException will be raised. If waittime
132 is 0, no waiting is done, and if jobs are not complete, the 131​ is 0, no waiting is done, and if jobs are not complete, the
133 exception will raise immediately. 132​ exception will raise immediately.
134 """ 133​ """
134​ if not job_ids and not build:
135​ raise ValueError("wait_and_report requires either job_ids or build.")
136​
135 if waittime is None: 137​ if waittime is None:
136 waittime = CONFIG.getint('report', 'jobs-wait') 138​ waittime = CONFIG.getint('report', 'jobs-wait')
137 # Use the openQA client lib to wait for jobs to be done. Will 139​ # Use the openQA client lib to wait for jobs to be done. Will
138 # raise an openQA client error on wait expiry. 140​ # raise an openQA client error on wait expiry.
139 client = OpenQA_Client() 141​ client = OpenQA_Client()
140 if job_ids: 142​ # iterate_jobs can work on jobs or build; whichever is set will be used
141 jobs = client.wait_jobs(job_ids, waittime=waittime) 143​ for joblist in client.iterate_jobs(jobs=job_ids, build=build, waittime=waittime):
142 elif build: 144​ report_results(joblist, wiki=wiki, report=report)
garretrazielUnsubmitted
Not Done

I don't think that it's necessary to instantiate generator like that, I believe that you can do:

for joblist in client.iterate_jobs(jobs=job_ids, build=build, waittime=waittime):

but nvm.

adamwillAuthorUnsubmitted
Not Done

oh, yeah - it's actually that way because at first I had two different iterate_jobs() calls for job_ids and build, then realized I could just use one and it'd work with whichever was set, but didn't notice it could then be optimized one step further :) I'll clean it up for commit.

143 jobs = client.wait_build_jobs(build, waittime=waittime) ​
144 else: ​
145 raise ValueError("wait_and_report requires either job_ids or build.") ​
146 return report_results(jobs, wiki=wiki, report=report) ​
147 ​
148 145​
149def report_results(jobs, wiki=None, report=None): 146​def report_results(jobs, wiki=None, report=None):
150 """Report results from openQA jobs to Wikitcms. jobs is an 147​ """Report results from openQA jobs to Wikitcms. jobs is an
151 iterable of openQA job dicts. If report is False, will just print 148​ iterable of openQA job dicts. If report is False, will just print
152 out the python-wikitcms ResTups for inspection. If report is None, 149​ out the python-wikitcms ResTups for inspection. If report is None,
153 will read the setting from the config file; if no config file is 150​ will read the setting from the config file; if no config file is
154 present, default is True. 151​ present, default is True.
155 """ 152​ """
Show All 23 Lines