How do you decide whether go test -race runs on every pull request, only nightly, or only over some packages?

## The decision, stated honestly Running the race detector is not free and its value is not uniform, so somebody has to decide where the instrumented minutes go. That person is usually whoever owns the CI budget, and they can be overruled — by an engineering lead after a race reaches production, or by the same budget owner after the bill arrives. Treating it as a purely technical question is the mistake; it is a spend allocation with a risk attached, and it should be argued as one. ## What each posture actually costs **Every pull request.** The strongest posture, and the one with the best economics per race found, because the report arrives while the author still has context and the change is small enough that the diff and the stack line up. Cost: every push pays for an instrumented build and run, which is several times the plain suite. On a busy repository that is a real line item, and it is also latency — developers wait on it. **Nightly, or on a schedule.** The cost moves off the critical path entirely and the developer experience is unchanged. What you lose is attribution: a failure covers everything merged that day, so somebody has to bisect, and that somebody is rarely the author. Races also live on the main branch until the next run, so anything cutting a release inside that window ships them. The practical failure mode is worse than the theoretical one: nightly race failures tend to accumulate an owner of nobody. **A package subset per pull request.** The pragmatic middle. Races require concurrency, so instrumenting the packages that start goroutines, hold caches or share state captures most of the risk for a fraction of the minutes. The weakness is drift: the list is correct on the day it is written, and six months later a package that had no goroutines has three. Mitigate it with a rule — any package that gains a goroutine gains the detector, and any package implicated in a production race is added permanently — and by running the full tree under the detector on a slower cadence so drift is eventually caught. ## How I would actually decide Measure first. Run the whole suite under `-race` once and record duration and peak memory per package. That single number turns the argument from opinion into arithmetic: if the instrumented run costs a few extra minutes, the debate is over and it goes on every pull request. If it costs half an hour and OOMs the runner, you have a scaling problem to solve before you have a policy question. Then exhaust the engineering levers before cutting scope. Shard the tree across parallel jobs. Persist the build cache so each job is not rebuilding the instrumented standard library. Check you are not running the whole suite twice — once plain, once instrumented — when the instrumented run already covers it. Size the runner for the detector's memory rather than accepting an OOM as a fact of life. Reducing what runs under the detector is the last lever, not the first, because it is the only one that removes signal. Then write the policy down with its exit criteria: what runs where, why, who owns it, and when it is next reviewed. ## Protecting the gate Whatever the posture, two failure modes matter more than the scope decision itself. The first is a gate that has stopped gating. The detector's value in CI rests entirely on the non-zero exit failing the step. A step that forces success, or that only greps the log, is a job that costs money and reports nothing. Audit for that specifically; it is the most common way a race check dies. The second is silent removal. `-race` disappearing from a command line in a routine pipeline change is a coverage decision made by whoever was unblocking their build that afternoon. Make it visible: the flag lives in a place with review, exclusions are listed with a reason and a date, and the list is reviewed on a cadence rather than accumulating forever. ## When you are overruled If a race reaches production, the conversation reopens and you should already know what you will say: which posture was in force, whether the racing package was covered, and what the coverage would have cost. If it was excluded to save minutes, the honest answer is that the trade was wrong for that package and it moves to the per-pull-request set permanently. If it was covered and the detector still missed it — because no test exercised the path — then the answer is not more instrumented minutes at all but a test that drives the path, and saying so plainly is more valuable than promising to run more.