Before the PIFR 2 switch, when a patch was marked green, the # of passes and fails was noted along with the success message.

We've already seen patches return green with something like 300 passes, because fatal errors prevented most tests from actually running.
So this information would be precious to have back. We're not to the point where a green report is a 100% certain indicator.

Comments

boombatower’s picture

boombatower commented
Status: Active » Postponed (maintainer needs more info)

My issue with that is:

Now that we support multiple environments...what should the message that is sent back contain? Say we have MySQL, Postgres...which will have slightly different counts since some tests will run differently...and say we add coder and performance....what should the summary contain?

When one environment fails...that makes it easy, but when they all pass, not so much.

Maybe we should just encourage clicking the link...I don't really know.

If you think of some consistent way that would be possible to implement I am all ears.

yched’s picture

yched commented
Status: Postponed (maintainer needs more info) » Active

Hm, right, not simple...

Problem is that the column of the results table that contains the patch filename takes an arbitrary width.
I guess that depends on how many different environments are expected ?
Playing with firebug, something like "Passes: 1 xx,xxx, 2 xx,xxx, 3 xx,xxx, 4 xx,xxx, 5 xx,xxxx" still fits in with a patch name like long-name-and-enven-longer-and-longer-and-longer.patch.
Though of course, this will not scale if more environments are targeted...

boombatower’s picture

boombatower commented

So then I guess that begs the question...should the summary message just change to that...and then I just always append all summary messages to create finally summary message.

yched’s picture

yched commented

I don't think I understand your question ;-)

boombatower’s picture

boombatower commented
Status: Active » Postponed (maintainer needs more info)

As in the summary message generated normally contains pass, fail, exception...since these messages are generated via plugin...I need a clean way to extract a shortened version.

Either another function besides summary() or assume that all plugins provide a shorter message when everything passed. That way all the messages can be stringed together as you suggested.

So say we add coder, it would normally return something similar to simpletest as a summary, but when it had no issues it would shorten it to something like "no issues with files" or "500 passes" w/e?

Currently they all do 500 passes, 0 fail, 0 exception. Which your suggestion only works if they shorten. So I guess it is a must, just trying to make sure it makes sense.

boombatower’s picture

boombatower commented
Status: Postponed (maintainer needs more info) » Fixed

#663456: Sudo-grouping: Group reviews by plugin will solve this.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.