This is UI oddness, you're doing everything right.

arc uploads a separate lint/unit status value, which is what's shown in the UI -- it isn't currently derived from the actual tests, so supplemental tests don't affect the UI.

This behavior is miselading, although fixing it isn't as simple as just reading something else because the arc status has additional information (notably, a "skip" status if the user skipped with --nounit or --nolint).

+@avivey -- We talked about this briefly on IRC yesterday.

Basically, I think the way forward is something like:

• We should preserve the fact that the user typed --nounit / --nolint in the UI, even if other processes have added build information later.
• We should otherwise consider all the tests when showing the overall status.
• If there are 5K test results, it would be nice to not have to load 5K tests every time we're rendering the page. But I think there isn't an obvious place to cache this right now.

Should we move the coverage information out of the individual tests? I don't remember any tester that actually reports coverage per test, and we just merge the whole thing anyway on the display.

IIRC we report coverage per-test, for whatever little that's worth.

Offhand, I don't think it's particularly valuable to keep it separate, but it seems a little silly to just throw it away for no reason. We could maybe provide a more formal way to report "coverage for all tests" for test engines that don't have per-test coverage metrics. Today they presumably just shove the coverage on an arbitrary test result. Are you running into something in this vein?

I was thinking it would make the aggregation-for-display easier, but yes, I often end up adding a "fake test" test with the coverage information.

Here's what I'm thinking here:

• Add lint/unit/coverage "summary" field to each Build.
• Recalculate whenever new lint/unit objects show up (Possibly offline via daemon).
• arc-side lint/unit already generates a Build, so this one will hold the --nolint/--nounit information (+ excuse?)
• Anywhere we currently show that information, load the summary information and aggregate that, instead of aggregating all lints/units directly.

This will also solve the "loading revision with 50k tests is slow" issue, because we will no longer load 50k tests for it, and it will include the right stars in Revision History if you have CI configured.