ci: warm test-bench cache on push to main

test-bench previously only triggered on pull_request, so there was never
a base-branch cache on main. Every new PR and merge-queue run started
cold, because GitHub's cache isolation only allows fallback to the base
branch — not to other PRs or branches.

Add push triggers for main and release/** so that after each merge a
cache-warming run compiles all test binaries (GOCACHE + GOMODCACHE) and
saves them under the main branch scope. PR first-pushes and merge-queue
runs can then restore from that warm cache instead of starting cold.

On non-pull_request events the benchmark step is skipped and replaced
with `go test -run=^$ ./...`, which compiles every test binary but runs
nothing. Correctness is already guaranteed by the merge queue before
commits land on main, so re-running benchmarks there is unnecessary.

Also add workflow_dispatch for manual triggering (required by project
guidelines), and document the cache isolation model and the
compile-only warming pattern in .github/README.md.

Author: anacrolix

.github/README.md

@@ -94,6 +94,58 @@ unnecessary re-runs.
 This is also why the `execution/tests/` package is broken into focused sub-packages
 rather than one monolithic package.
 
+### Cache warming and GitHub's cache isolation rules
+
+GitHub Actions caches are scoped by branch. A workflow run can restore caches from:
+
+1. **Its own branch** — caches saved by earlier runs on the same branch.
+2. **The base branch** (`main`) — caches saved by any workflow run on `main`.
+
+It cannot access caches from other PRs or other branches.
+
+**The cold-start problem** — If a workflow only triggers on `pull_request`, it never
+runs on `main` and therefore never populates the base-branch cache. Every new PR
+opens to a cold cache, even if the codebase hasn't changed at all. Subsequent pushes
+to the *same* PR do find each other's caches, but only until the GitHub-hosted cache
+is evicted (repos share a 10 GB limit; busy repos evict older entries within hours).
+
+**The fix** — add `push: {branches: [main, release/**]}` as a trigger. After each
+merge, a run warms the build and module caches on `main`. All future PR first-pushes
+restore from that warm base-branch cache instead of starting cold.
+
+**Cache warming without test validation** — For workflows where correctness is already
+enforced by the merge queue, the push-to-main run exists purely for cache warming. To
+prevent benchmark or test flakiness from showing as failures on main commits, use
+compile-only steps on non-PR events:
+
+```yaml
+- name: Run benchmarks
+  if: github.event_name == 'pull_request'
+  run: make test-bench
+
+- name: Build test binaries (cache warming)
+  if: github.event_name != 'pull_request'
+  run: go test -run=^$ ./...
+```
+
+`go test -run=^$` compiles every test binary (identical GOCACHE entries to a full
+run) but executes nothing. The job always succeeds, and the commit on `main` shows
+green. If a benchmark were broken post-merge it would have been caught by the PR or
+merge queue run before landing.
+
+**Merge queues** — `merge_group` runs use a temporary synthetic branch
+(`refs/heads/gh-readonly-queue/main/pr-N-SHA`). They can read from the base-branch
+(`main`) cache, so they benefit from the warm cache created by the `push` trigger.
+However, caches *saved* during a merge-group run are stored under that temporary
+branch and become inaccessible once the merge group completes — they do not
+contribute to the `main` cache. Only the `push`-triggered run after the merge creates
+a durable base-branch cache.
+
+**Implication for workflow design**: any workflow that should benefit from caching
+across PRs and merge queue runs needs a `push` trigger on `main` (or a nightly
+schedule on `main`). Without it, each PR and each merge-queue batch is always a cold
+start.
+
 ## Required checks
 
 Required checks exist to block *regressions*, not to enforce perfection.

.github/workflows/test-bench.yml

@@ -1,10 +1,9 @@
 name: Benchmarks
 
-# We only run benchmarks on pull requests to catch accidental breakage early.
-# We don't run on push to main/release because benchmarks aren't actively used
-# for anything right now — if they break post-merge it's not a release blocker.
-# If we ever care about benchmark results over time, that would be a separate
-# workflow on main that tracks performance trends, not this one.
+# Run benchmarks on pull requests to catch accidental breakage, and on push
+# to main/release to keep a warm build cache. Without a push trigger,
+# test-bench never runs on main and every new PR starts from a cold cache,
+# because GitHub's cache fallback chain only reaches the base branch.
 on:
   pull_request:
     branches:
@@ -14,6 +13,17 @@ on:
       - reopened
       - synchronize
       - ready_for_review
+  push:
+    # Cache warming only — benchmarks are not re-run on push to main/release.
+    # GitHub's cache isolation means PR and merge-queue runs can only fall back
+    # to the base-branch cache. Without this trigger, test-bench never runs on
+    # main so every new PR starts cold. The push run compiles test binaries
+    # (warming GOCACHE and GOMODCACHE) but does not execute them; correctness
+    # is already guaranteed by the merge queue before the commit lands here.
+    branches:
+      - main
+      - release/**
+  workflow_dispatch:
 
 defaults:
   run:
@@ -40,7 +50,12 @@ jobs:
         id: erigon
 
       - name: Run benchmarks
+        if: github.event_name == 'pull_request'
         run: make test-bench
 
+      - name: Build test binaries (cache warming)
+        if: github.event_name != 'pull_request'
+        run: go test -run=^$ ./...
+
       - uses: ./.github/actions/cleanup-erigon
         if: always()