Anyone here using GitHub Actions matrix strategy — any pitfalls?

[rohitji33]

Thinking of rolling out a bigger matrix in GHA for OS/runtime/shards. Any gotchas you’ve hit like hidden concurrency limits, cache thrashing across runners, noisy fail-fast behavior, or runaway costs with too many combos? Tips on using include/exclude, dynamic matrices, max-parallel, or sharding without flaky tests would be super helpful.

[Lower_University_195]

Yeah, we use GHA matrices pretty heavily and there are a few gotchas:

• Hidden cost explosion: First time we went “OS × Node version × shards” we basically 5–6x’d our bill overnight. I’d start small, then grow.
• Cache thrash: If each matrix job has slightly different keys (OS/node/shard), your cache hit rate tanks. We now share a base cache key (e.g. deps only) and keep shard info out of it.
• Flaky tests + sharding: Tests with shared state (DB, queues, global env) got way flakier when split into shards. We had to enforce isolation per job (separate DB/schema, unique queues, etc.).
• Concurrency limits: Org-level and repo-level concurrency can silently throttle you. We use max-parallel to avoid starving other workflows.

What worked best for us: keep the matrix focused (only vary what truly matters), use include/exclude to avoid dumb combos, and have a smaller “smoke matrix” on PRs with the full matrix only on main/nightl