Document: XML report loading does not load record value.

[mpotter@…]

From ​Google Group Discussion, specifically ​osimons Feb 19, 7:16 pm and ​potter Feb 20, 12:41 pm.

For a given XML report, example:

<report category="cat">
    <record1 attr1="val1" attr2="val2">
        <param1>val3</param1>
        <param2>val4</param2>
        Record Value
    </record1>
    <record2 attr1="..." attr2="...">
      ...
    </record2>
</report>

For each record a set of entries is made into the database, example:

report	item	name	value
123	1	category	cat
123	1	type	record1
123	1	attr1	val1
123	1	attr2	val2
123	1	param1	val3
123	1	param2	val4

However, the "Record Value" currently is not stored.

This impacts anything that generates or uses ​"lint" reports, including:

• python:pylint Build Recipe Command, trunk/bitten/build/pythontools.py?rev=799#L131 source​
• #507: Lint reports do not show the actual problems, only some statistics.
• #508: [PATCH] Support the Cppcheck C/C++ lint checker.

Possible solutions:

• Change the XML loader to: As the record name becomes the "type" value, the record value becomes the "value" value.
• Explicitly document that the record value is not supported, change the "lint" report to set the lint message into a newly named attribute/parameter, change the above impacted tickets/features to use this new named attribute/parameter.
• Other?

Currently I prefer the first solution, but do not have a strong opinion ether way. However, would like to know which solution shall be used since that impacts other efforts.

[hodgestar]

I'd prefer option two as less likely to break any custom uploads lurking out in the wild. I'm adding a patch which implements this for the lint report to #507.

[mpotter@…]

From code reading then I take it that lint reports will use "msg" for the message instead of the "problem" record value. Thanks.

[mpotter@…]

This is boiling down to: The Lint Report XML format needs to be properly documented. After that, other efforts will need to take these changes into account.

Assuming that the python:pylint source code​ is the definitive source for what should be done, I attempted to analyse what this code does. From this:

• msg_type is initially a single uppercase character followed by 0 or more numbers: [A-Z]\d*. L139​ L151​
• If msg_type begins with 'W', 'E', 'C' or 'R' then category becomes 'warning', 'error', 'convention', or 'refactor' respectively, otherwise category is None. L142​ L152​
• If msg_type is only a single character then msg_type is changed to None. L153​
• filename is initially a string of 1 or more characters: .+
• If the filename is an absolute path and begins with the basedir, the basedir is removed.
• lineno is 1 or more digits: \d+
• tag is 1 or more: letters or period; or is None.
• The XML is then generated using the attributes=values: L162​
  • category=category
  • type=msg_type
  • tag=tag
  • line=lineno
  • file=filename

This would mean, in the XML:

• Assuming a properly formed pylint file (I may be assuming what is "properly formed")
  • category: required, "convention|warning|refactor|error"
  • type: optional, [CWRE][0-9]+
    • If not given it will appear as "problem" in the database.
  • tag: optional
  • line: required
  • file: required
• If not properly formed, the following could change:
  • category: optional, "convention|warning|refactor|error"
  • type: optional, [A-Z][0-9]+

Comments?

[mpotter@…]

J. Berger <jeberger@…> in #507:

As far as the XML fields are concerned, both category and type should always be there (at least for pylint and cppcheck reports).

• category should properly be called "severity" and tells how important the problem is. Bitten should probably define a set of standard values which all checker plugins must use (cppcheck uses "error", "warning" and "convention" to be as close as possible to pylint);
  
• type is a tool-specific code designating the precise type of problem. For example, an invalid function name and a missing docstring are both in category "convention", but they have different types (C0103 and C0111 for pylint).

[osimons]

Note that the report format docs was migrated to repository in [896], so a patch would be needed now to make changes.

[hodgestar]

Wrap lint messages in a <msg> tag so that they are captured when reports are uploaded.

[hodgestar]

I'm trying to land my patch for #507 so I thought I'd start by committing the part relevant to this bug. Patch includes updated documentation and a test.

The patches view point is that the generic report loading functionality never intended to support loading text from directly inside <report> child elements and that the lint reporter should have wrapped the message in a <msg> element (which is what my patch does).

[hodgestar]

Committed in r997 and backported to 0.6.x in r998.