implement check.export_TAP()
ClosedPublic

Authored by kparal on Mar 14 2014, 2:29 PM.

Details

Summary

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.

Test Plan

Lots of new unit tests.

Diff Detail

Lint
Lint Skipped
Unit
Unit Tests Skipped
tflink accepted this revision.Mar 18 2014, 4:06 PM

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.

It's something that we could add to the data passed into libraries or possibly do a form of search-and-replace on TAP output to insert the $CHECKNAME

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?

I'd like to avoid confusion between the result sent to something like resultsdb (status, logs, what build/update/etc is related) and the PASS/FAIL/NEEDS_INSPECTION/etc result that is a component of the other result. Do you have any ideas on how to make the naming more intuitive?

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.

That makes sense to me, it doesn't have TAP specific code in the CheckDetail which would hopefully make any transition to subunit less painful in the future.

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.

Hrm, I hadn't looked at the output from bayeux that closely. It sounds good enough to get away with for the time being, though?

Looks good to me, though.

It's something that we could add to the data passed into libraries or possibly do a form of search-and-replace on TAP output to insert the $CHECKNAME

My idea was to create a global singleton Context class. Could be used like this:

from Context import context
print context.check_name
# either str or None, depending how you run it (runner or standalone)

We could also implement context.check_name_fallback() that would return os.path.basename(sys.modules['__main__'].__file__) or something like that.

The Context would of course be useful for lots of purposes. It's not always viable to pass all values through method parameters, sometimes you need... well, some context :-)

I'd like to avoid confusion between the result sent to something like resultsdb (status, logs, what build/update/etc is related) and the PASS/FAIL/NEEDS_INSPECTION/etc result that is a component of the other result. Do you have any ideas on how to make the naming more intuitive?

Using 'outcome' word for PASSED/FAILED/etc is one way to have consistency. The other way is to use 'result' for that and rename Result table in ResultsDB-sense to something else, but I don't have any idea what that should be.

That makes sense to me, it doesn't have TAP specific code in the CheckDetail which would hopefully make any transition to subunit less painful in the future.

What exactly do you mean by subunit? I'm a bit lost.

Hrm, I hadn't looked at the output from bayeux that closely. It sounds good enough to get away with for the time being, though?

Yes, it's perfectly fine for the time being, I believe.

@jskladan, are you OK with the sample TAP output as well?

Josef has become sick, I'll push this now.

kparal closed this revision.Mar 20 2014, 9:51 AM

Closed by commit rLTRN23d387af43f9 (authored by @kparal).