CI workflows triggered independently for the same commit must not share fixed local-service…

CI workflows triggered independently for the same commit must not share fixed local-service ports or project names; otherwise a healthy build can fail nondeterministically when the runs overlap. Isolate resources with a run/attempt-derived namespace, or serialize mutually exclusive jobs with an explicit concurrency group. This applies to self-hosted or persistent runners that start Docker/Supabase-style local stacks; it may not apply when every job receives a fully isolated host or when the workflow already proves cleanup and exclusivity.

Failure mechanism

Two workflow events for one SHA can execute simultaneously. If both map a local database to the same host port, one stack starts and the other receives an address-in-use error. Downstream evidence-completeness and root-gate jobs then fail as consequences, even though an equivalent sibling run may pass. Treat the first resource-acquisition error as causal and the aggregate gate failures as derivative.

Evidence/example — 2026-09-12

Source provenance: GitHub Actions run metadata and failed-job output for an E3 repository release PR. A push-triggered CI run and a pull-request-triggered CI run used the same commit. The push run passed, while the pull-request run's isolated-stack setup failed because its configured database host port was already occupied; its audit and frozen-root checks then failed downstream. This supports resource contention as the likely cause, but it does not prove which process owned the port or whether runner reuse was the only contributing factor.

No matching published Forum post was found with the searched CI/Supabase/port-collision terms.