build/github: quiet bazel output in unit_tests CI job

[tbg]

Cuts the unit_tests GitHub Actions log from ~2,800 lines on a green run to ~400 (–85%) by removing several orthogonal sources of bulk. The actual failure signal (test name, target, EngFlow invocation link) is preserved or made more prominent.

Measured impact

Metric	Before	After	Δ
Total log lines	2,781	409	–85%
Per-target PASSED roster	919	0	–100%
Metamorphic/GoMockReflect blocks	many	0	–100%
Bazel build progress [N / M]	910	14	–98%
Failed test surfacing	inline test.log dump	summary + EngFlow link	clearer

Sources removed

1. Bazel build progress ([N / M] ..., ~33% of baseline) — suppressed via --noshow_progress.
2. Per-test summary roster (//pkg/...:foo_test (cached) PASSED in 0.1s for ~900 targets, ~33% of baseline) — suppressed via --test_summary=terse. The "Executed N out of M" line stays so the overall run shape is still visible.
3. Inline per-test failure dump (full captured stderr/stdout of any failing target, often ~99% noise per failure) — --test_output=summary replaces it with one FAILED line plus the EngFlow invocation link. summarize-build.sh continues to publish per-test failure annotations on the PR.
4. gomock reflect helper preamble — pkg/util/metamorphic.init() was running in every Go binary built with the crdb_test tag, including the rules_go reflect helpers that link a package being mocked. Their stderr was captured by bazel as INFO: From GoMockReflectExecOnlyGen ...: and emitted to bazel's stdout (so neither --test_output=* nor any test-level setting could suppress it). Fixed at the source by gating metamorphicEligible() on testing.Testing() so only actual Go test binaries initialize.

Note on --remote_download_outputs warning

The bazel warning about --remote_download_minimal conflicting with --remote_download_toplevel (from --config=engflowpublic) still appears but is harmless. Bazel gives explicit command-line flags precedence over config expansions, so minimal is in effect as intended. A code comment documents this.

Verified

A throwaway commit deliberately breaking TestAnnotateCtxTags was pushed to confirm the failure surfaces clearly under the new configuration. Output:

FAIL: //pkg/util/log:log_test (see .../test.log)
INFO: Build completed, 1 test FAILED
//pkg/util/log:log_test  FAILED in 6.8s
| `//pkg/util/log:log_test` | `TestAnnotateCtxTags` | `FAILURE` | [Link](https://mesolite.cluster.engflow.com/...) |

Epic: none

[trunk-io]

😎 Merged successfully - details.

[cockroach-teamcity]

This change is 

[blathers-crl]

It looks like your PR touches production code but doesn't add or edit any test code. Did you consider adding tests to your PR?

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}

[blathers-crl]

Detected infrastructure failure (matched: self-hosted runner lost communication with the server). Automatically rerunning failed jobs. (run link)

responded

[tbg]

You're correct - the removal was not a no-op. Here's the analysis:

Key Finding

Bazel's precedence is explicit command-line flags > config expansions, regardless of argument order. This means --remote_download_minimal on the command line overrides --remote_download_toplevel from --config=engflowpublic, even when the config appears later.

Evidence

1. Empirical testing with bazel canonicalize-flags:

# Config AFTER explicit flag (the actual CI order)
$ bazel canonicalize-flags -- --remote_download_minimal --config engflowpublic
--remote_download_outputs=minimal

# Just the config (no explicit flag)
$ bazel canonicalize-flags -- --config engflowpublic
(none - uses default toplevel)

2. Verification from actual CI logs (PR #170724):

The command runs with both flags and shows the warning, but minimal was actually in effect.

3. Bazel documentation:

From bazelrc docs: "Options on the command line always take precedence over those in rc files."

Behavior Change

• Before (with flag): --remote_download_outputs=minimal → downloads only final outputs
• After (without flag): --remote_download_outputs=toplevel → downloads top-level outputs (more data)

The warning was real, but the explicit flag was winning. I'll revert this change.

done