Rename some CheckDetail attributes to match TAP and ResultsDB
terminology:
CheckDetail.name -> CheckDetail.item
CheckDetail.result -> CheckDetail.outcome
CheckDetail.result_order -> CheckDetail.outcome_priority
CheckDetail.update_result -> CheckDetail.update_outcome
Add new attribute CheckDetail.report_type and introduce enum ReportType.
Example TAP output from 3 CheckDetail instances:
ok - $CHECKNAME for Koji build xchat-0.5-1.fc20 --- details: output: |- xchat.x86_64: W: file-not-utf8 /usr/share/doc/xchat/ChangeLog xchat.x86_64: W: non-conffile-in-etc /etc/gconf/schemas/apps_xchat_url_handler.schemas xchat.x86_64: W: no-manual-page-for-binary xchat item: xchat-0.5-1.fc20 outcome: PASSED summary: 5 ERRORS, 10 WARNINGS type: koji_build ... not ok - $CHECKNAME for Bodhi update foobar-1.2-3.fc20 # FAIL --- item: foobar-1.2-3.fc20 outcome: FAILED summary: dependency error type: bodhi_update ... ok - $CHECKNAME for Yum repository f20-updates --- item: f20-updates outcome: INFO summary: 2 stale updates type: yum_repository ...
I consider this to be a preliminary review. There are still some unsolved issues which might or might not get included in this patch.
a) the libraries can't access the name of the currently running check, only directives can. From that reason I place $CHECKNAME in the TAP result line. Of course, we don't really need to have the name there, it just makes it a bit more readable. This either needs to be solved in a different ticket or the word needs to be removed.
b) the TAP structure is not yet finalized, but it's something that @jskladan proposed in T84
c) I'm not fully convinced that result -> outcome rename is intuitive. On the other hand, ResultsDB uses "result" differently, it's a whole object which contains 'outcome' as an attribute:
https://fedoraproject.org/wiki/AutoQA_resultsdb_schema
http://resultsdb.qa.fedoraproject.org/resultsdb_frontend/jobs
So I'd like to stay consistent with our ResultsDB UI. Maybe we should even rename whole CheckDetail to CheckResult?
d) Maybe export_TAP() should not be in check module, but we should rather move it to tap module as tap.fromCheckDetail(). Is that more logical or not? But in that case we need to solve T101 first.
e) the TAP output produced by mcepl's bayeux library is not fully matching the spec (for example there should be no # FAIL directive in the second output, also the - separator between ok and rest of the line is redundant. We might want to adjust it in the future.