The wikitcms changes behind this are moderately large: all the changes since 1.10.3 are basically part of the background for this. The ValidationPage add_results() method handles editing multiple results into a single page, and the Wiki report_validation_results() method handles getting ValidationPage, ResultRow and Result instances from the passed tuple attributes, creating a results dict in the correct form for add_results(), and calling add_results() for each affected Page.

I also implemented some caching for Page API queries - for page text and the list of page sections - to avoid repeated remote queries as we work through the list of results.

It does make wikitcms more complex, but I don't think it's going into the realm of building custom interfaces that'd be no use to other callers; a high-level 'just report a bunch of results and handle the details for me' function is something that could certainly be useful in other ways, and the caching is a clear performance improvement.

Hah - I actually thought of doing that initially, but figured you might think it was over-complicating things :) I use namedtuples for a couple of things in fedfind. +1, I'll do it.

So there's one issue with the namedtuple approach. The tuples that report_validation_results() returns for duplicate reports are not the original objects it was passed, for...$REASONS. They're reconstructed by wikitcms during the process. So I can do the change, and we could then avoid the magic const at line 53, but we can't avoid the ones at line 72 because they're coming from report_validation_results() output, which won't be our namedtuple.

So...here's a thought: wikitcms could define a namedtuple class for this case. You can pass report_validation_results() an instance of that class, or just a regular tuple. Whichever you pass, it returns instances of that class.

Then report_job_results could import that class from wikitcms and pass in its results using it. That way we wouldn't be doing the same work both sides and wouldn't run the risk of the names used in the namedtuple diverging between the two. wikitcms would still not be imposing any mandatory complexity on callers, as they could ignore the namedtuple stuff entirely and just pass in a regular tuple and treat what they get out as a regular tuple, if they like.

WDYT?

if you're interested in the $REASONS, it's basically because wikitcms tries to be forgiving about the input for report_validation_results(). It will accept incomplete data so long as it's satisfied it can reliably guess what was intended. So the input tuple might have only a partial testcase name and no section or testname at all, for e.g. - that can be OK, if the partial testcase name alone identifies a single 'test instance' in the given page.

But the actual result reporting needs to use ResultRow() instances, which have full and precise data. report_validation_results() passes page.add_results() the ResultRow() instance - but it's page.add_results() which figures out whether a given result is a dupe of an existing report or not. It doesn't make sense for report_validation_results() to do that work.

So page.add_results() figures out the dupes and passes the info back to report_validation_results() - but page.add_results() doesn't know what the sloppy original input tuple was, it only knows the ResultRow() instance it was passed. page.add_results() outputs dupes as (ResultRow, env, Result) tuples, and report_validation_results() parses those back into the 12-tuple format to be returned.

The only way to avoid this, I guess, would be to have report_validation_results() keep track of the ResultRow and env it passes to page.add_results() and then do some work to parse the dupes list it gets back, and figure out which dupe came from which original tuple. I dunno, that seems kind of a mess, and not even necessarily the 'right' thing. And there's still another issue with that approach - page.add_results() fixes up imprecise env if it can (so if you pass it 'X8' and the envs for the test are 'x86' and 'ARM', it figures out you meant 'x86') and returns the fixed value (not the sloppy submitted one) in the dupe dict. I could change that too, but...again, not sure it's the right thing to do.

report_results() is what openqa_trigger.py calls.

Splitting it up this way is actually a leftover from the crash reporting stuff - I pulled the refactoring at the bottom in from that branch and re-purposed it. On the other branch it called report_passes() then report_crashes(), and the CLI bits let you choose whether to call one or the other or both.

While we're only reporting passes, having both report_results() and report_passes() seems a bit unnecessary indeed. We could drop the stubby report_results() and rename report_passes to report_results, I guess.

I think that this differential request is already merged. Please close it.