Ashwin Kumar Sivakumar e8651cf6c6 perf(ci): parallelize service builds across all 3 runners via matrix strategy ... The build was structured as a single job looping through all ~20 services sequentially, so only 1 of the 3 deployed runner pods (one per worker node) was ever used - the other 2 sat idle for the entire build. Switched to a static per-service matrix (max-parallel: 3, matching the 3 runners at capacity 1 each) so independent services build concurrently. Each matrix job does its own quick "does this service need building" check up front (same change-detection logic, now per-job) rather than relying on a shared job output, to avoid needing cross-job artifact/output passing. GitOps updates also move into each matrix job (previously a single step at the end) since there's no longer one job aggregating all results - added a fetch/reset/retry loop since multiple jobs can now push to the same gitops branch concurrently. Tried adding cargo registry/target cache mounts to Dockerfile.simple for a bigger per-build win too, but measured it directly (local A/B: cold build 2m37s vs a second, supposedly-cached build 7m18s) and it made things slower here, likely cargo's own cache-verification pass outweighing the benefit for this dependency set - reverted that part, Dockerfile.simple is unchanged. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>		2026-07-08 01:54:47 +05:30
..
scripts	chore: migrate ci naming to forgejo	2026-06-11 17:17:42 +05:30
workflows	perf(ci): parallelize service builds across all 3 runners via matrix strategy	2026-07-08 01:54:47 +05:30