This adds a jobs_from_update function to schedule jobs for a
specified Bodhi update, a CLI subcommand for doing this, and
adjusts the scheduling fedmsg consumer to do it automatically
whenever a critpath update is created (technically, whenever a
push to 'testing' is requested, but that's almost always on
creation) or edited. It also adjusts the reporting code to
handle update test jobs: the consumer and CLI code do not need
adjustment. We can tweak this in future to run the tests for
updates with particular packages or whatever, just running for
every critpath update seems like a good place to start. I
specifically didn't get any smarter about only running the tests
if the edit changed the packages because it lets us say 'if you
want the tests to be re-run, just edit the update'.
Details
- Reviewers
jsedlak - Commits
- rOPENQA78007b5c1fa4: Add update job scheduling and reporting
The test suite was extended, so check that :) Also,
try scheduling jobs via the CLI, and if you can, by using the
testing consumer and replaying appropriate fedmsgs (or just
turning on the prod consumer, pointing it at your openQA
instance and waiting...). Try reporting an update job result
to a local test instance of ResultsDB using the CLI. Note:
you need the very latest resultsdb_conventions release (so use
git master or grab the package from Koji).
Diff Detail
- Branch
- update-jobs (branched from master)
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 1081 Build 1081: arc lint + arc unit
Make reporting work too
I meant to do this as a separate commit, but in fact the changes
needed for reporting are quite small, so may as well just throw
them in with this diff.
Oh, forgot to mention - this diff will also make all ResultsDB reports include an arch extradata item (including the compose results, as well as the update results).
I'm kinda wondering if we made the wrong call with the test case naming, also, by adding the 'test type namespace' thing to it - so we'll report results for test update.base_selinux when running the base_selinux test on an update, but for test compose.base_selinux when running the base_selinux test on a compose. I'm really not sure if that was a sensible idea. Maybe we should think about it again? If we change it it'll make all the results we've submitted so far 'incompatible' with future results, but meh, we weren't doing anything with those results yet anyway.
Hmm, code looks OK, but for some reason, trying to run python fedora-openqa.py report --resultsdb "Update-FEDORA-2017-f519ebb3c4" reports only one job from two that were run and are passed into resultsdb.
See above. I'm not sure whether this is your change or whether this was there from my code, but it needs fixing.
| fedora_openqa/report.py | ||
|---|---|---|
| 414 | This is culprit! You cannot return, because you are iterating in for over several jobs. | |
This is culprit! You cannot return, because you are iterating in for over several jobs.