Comment on #17332 Should we stop marking `XResult` as uncacheable for fmt/fix/lint/test/etc... Discussion answered by stuhood The scope of

uncacheability

for a

@rule

is a bit different:

Can see that the log is printed very quickly showing the result was cached

On the first run of

pantsd

, this would happen regardless of whether the

@rule

was marked uncacheable, because the

@rule

cannot hit a persistent cache: only the processes below it. So I think that for the case you're thinking of (lots of output in CI...?), it would not have any impact. The only time the result would cease to be printed would be when the process below it re-ran within a single session, but did not change... almost certainly because it re-ran and hit the cache, but possibly also because it failed for a second time with exactly the same output. That latter case (failing again) is problematic. No matter how many times a test fails and re-runs, you'd want to see its output: even if it was identical to the last failure.

Pollutes the output with unhelpful information

I disagree that "a test completed" is unhelpful info in a CI situation... for one thing, some CI providers will kill your process if you don't render any output for at least N minutes: Travis did at least, not sure about Actions. And at the very least, a user might reasonably expect that something has hung. To remove this information, I think that it would need to be replaced with some other ongoing summary of work ("N processes queued, M processes completed, ...")... which I would be in favor of if we could reify enough information out of

@rules

to make it useful. pantsbuild/pants