ci: test.yaml is missing the concurrency cancel-in-progress block other repos have

[balbasty]

What

Found as a side effect of fastfields-lib#52 (ccache): rapid successive test pushes on the same branch raced and overlapped, colliding on the ccache-save step, because .github/workflows/test.yaml in this repo lacks the

concurrency:
 group: ${{ github.workflow }}-${{ github.ref }}
 cancel-in-progress: true

block that other C++/CUDA repos in the org already carry (e.g. fastfields-cpu-lib's lint.yaml, and the pattern used org-wide for the Python reusable workflows as of fastfields/.github#6).

Fix

Add the same concurrency block to this repo's test.yaml (and build.yaml/whatever else runs per-push here, if it doesn't already have one) so a newer push cancels a superseded in-flight run instead of letting them race.

Left out of fastfields-lib#52 deliberately to keep that PR's diff scoped to ccache only.

Workstream: claude-jitfields-to-fastfields

[balbasty]

Triage for the 0.0.dev0 release: confirmed non-blocking, deferred.

Confirmed this is purely about the GitHub Actions workflow concurrency group (cancel-in-progress on redundant CI runs), not runtime/algorithmic concurrency. Checked fastfields-lib's workflow set: test.yaml is a build/link-check job only (make all — this repo has no standalone test suite; correctness is gated by fastfields-cpu-lib) and there is no release.yaml in this repo at all — fastfields-lib isn't a PyPI-publishing repo, it's a C++ layer consumed as a submodule. So there's no release-automation race/double-fire risk here; the worst case today is exactly what's described — two overlapping pushes stomping each other's ccache save, which wastes CI time but can't produce a bad artifact or a bad release. Straightforward to add later (mirroring the fastfields/.github reusable-workflow pattern already used elsewhere in the org). Leaving open, not actioning now.

---

Generated by Claude Code