[manjari25]

Why?

//test/e2e/submitqueue runs three top-level suites (git merge, GitHub land, and the main e2e suite) one after another, each with its own Docker Compose stack. A run takes 254 to 291s against Bazel's default 300s timeout, so a slow runner or registry tips it over. That is failing merge-queue runs, for example the ones for PRs 910 and 911, where the log ends with panic: test timed out after 5m0s.

What?

• shard_count = 3 on the test: rules_go assigns top-level tests to shards by index, so each suite runs in its own shard, in parallel. Each shard gets its own 300s limit, and wall time drops to that of the longest suite.
• The suites use separate Compose project names, ephemeral ports, per-test temp dirs and content-hashed image tags, so they don't clash.
• The shard count has to match the number of top-level tests in the package; a fourth would share a shard.

Test Plan

• CI: the E2E job passed with three shards. //test/e2e/submitqueue took 145.9s (the slowest shard), against 254 to 291s before, so the 300s limit now has about 2x headroom.

Issue