ci(build): halve CI wall clock by parallelizing jobs and caching gems

[matthv]

Why

CI grew slow as datasources were added: 50 jobs, ~52 min of runner time, ~3 min 10 wall clock. Per-job breakdown from run 33058967442 showed no slow job — the cost was job count plus uncached bundle install eating ~60% of every job.

	Before	After
Jobs	50	27
Runner minutes	~52 min	~11 min 30
Wall clock	~3 min 10	~1 min

What changed

Lint: 26 jobs → 1. A single root .rubocop.yml governs the monorepo, so one bundle exec rubocop already lints all 840 files across the 13 packages — the packages matrix ran the identical command 13× per Ruby version. The per-package bundle install was dead weight on top: bundle exec at the root restricts activation to the root Gemfile, so rubocop never saw those gems anyway. TargetRubyVersion: 3.0 pins the parser, so the ruby-version dimension couldn't change the result either.

Verified against a pristine BUNDLE_PATH holding the root Gemfile alone — rails, sqlite3, mongoid, activerecord all absent from the load path, rubocop still exits 0 over all 840 files.

The unixODBC step goes with it (it only existed to build ruby-odbc for the snowflake bundle); it is retained in the test job, which still needs it.

Lint and test now run in parallel. They are independent; chaining them made the critical path the sum rather than the max. deploy now lists lint explicitly, since it previously depended on lint only transitively through test — without that, a release could ship with RuboCop red.

Gem caching on the shared BUNDLE_PATH, keyed on Gemfiles/gemspecs rather than the gitignored lockfiles. The test key names only its own package's Gemfile-test so a one-package PR doesn't miss on all 24 cells, while keeping every gemspec, since path: deps mean a sibling's gemspec still affects resolution.

The mirror-image dead weight in test, too. Install dependencies on main repo was just as dead there: the Test step runs entirely under BUNDLE_GEMFILE=Gemfile-test, all 12 matrix packages declare their own rspec / simplecov / simplecov_json_formatter in that file, and no other step touches root gems (Wait for MongoDB uses nc, Upload coverage reads the artifact). It cost 3.7s per cell — ~1 min 30 of runner time over the 24 cells — and pushed ~12MB of never-loaded gems into each of the 24 caches. Verified on a pristine BUNDLE_PATH the root Gemfile never touched: forest_admin_datasource_toolkit installs 49 gems from Gemfile-test alone and runs 478 examples, 0 failures, with coverage.json written. Dropping it makes the root Gemfile and *.gemspec components of the test cache key redundant, so they go too.

Concurrency group, same shape and placement as the one already in security-fixes.yml: a PR's in-flight run is superseded by its next push. cancel-in-progress is conditional rather than true because deploy publishes gems from main/beta — those runs must never be cancelled mid-flight. notify-ci-failure.yml only fires on branches: [main], so a cancelled PR run cannot trip it.

CLAUDE.md — the scaffolding checklist pointed at the lint matrix this PR deletes.

Review notes

Verified and cleared: hashFiles degenerating to an empty key (all patterns match real files); a restored cache serving stale gems (impossible — no committed lockfiles, so bundler re-resolves every run and /tmp/bundle is only an artifact store); deploy publishing without lint/test green (the if: carries no status function, so implicit needs gating holds); the qlty/ruby-version coupling (untouched); notify-ci-failure.yml (keys off the workflow name). Branch protection on main has no required status checks, so collapsing the 26 Lint (x, y) contexts into one cannot wedge PRs.

One accepted regression, narrower than first stated: no job resolves packages/*/Gemfile any more — the test job installs Gemfile-test, a different file in 11 of 13 packages. An unresolvable package Gemfile now goes green. Accepted because the signal covered 3 of 13 packages by accident of an inconsistency, tested a dependency edge absent from the published gemspecs (none of those three declares a forest_admin runtime dep), and never exercised PR code. A deliberate release-time install smoke test is the right home for that question.

Their syntax is still linted, though: RuboCop's default Include covers **/Gemfile, so bundle exec rubocop --list-target-files at the root already lists all 13 packages/*/Gemfile and all 13 packages/*/*.gemspec — 26 files. Only dependency resolvability is lost, which makes the trade narrower than the paragraph above first claimed. (Gemfile-test is not among those 26 — it falls outside that default Include.)

Follow-ups (not blocking, both pre-existing)

• zendesk, mambu_payments and graphql_hasura declare siblings without path: in their Gemfile, unlike the other 10 — so bundle install in those packages resolves published siblings rather than the working tree.
• forest_admin_test_toolkit is published to RubyGems but has no specs, no Gemfile-test, and now no CI entry at all.

🤖 Generated with Claude Code

Note

Parallelize lint and test jobs and add gem caching in build.yml

• Removes the needs: [lint] dependency from the test job so lint and test run in parallel, halving CI wall clock time.
• Adds gem cache steps to both lint and test jobs, keyed by OS, Ruby version, Gemfile, and gemspec files.
• Simplifies the lint job: drops the Ruby version matrix, runs once on Ruby 4.0 at the repo root with a single bundle install + rubocop.
• Adds workflow-level concurrency with ref-based grouping and cancel-in-progress for PRs to auto-cancel superseding runs.
• Updates CLAUDE.md to reflect that new packages no longer need lint matrix entries, and clarifies test matrix and coverage artifact path conventions.
• Behavioral Change: deploy now requires both coverage and lint to pass (needs: [coverage, lint]) instead of only coverage; packages without spec suites must be excluded from both the test matrix and coverage list.

^{Macroscope summarized b5d29b4.}

[qltysh]

Coverage Impact

This PR will not change total coverage.

🚦 See full report on Qlty Cloud »

🛟 Help

• Diff Coverage: Coverage for added or modified lines of code (excludes deleted files). Learn more.

• Total Coverage: Coverage for the whole repository, calculated as the sum of all File Coverage. Learn more.

• File Coverage: Covered Lines divided by Covered Lines plus Missed Lines. (Excludes non-executable lines including blank lines and comments.)

  • Indirect Changes: Changes to File Coverage for files that were not modified in this PR. Learn more.

[christophebrun-forest]

The mirror-image dead weight survives in the test job.

Install dependencies on main repo (build.yml:100) is dead weight there for exactly the reason the lint one was: the Test step runs entirely under BUNDLE_GEMFILE=Gemfile-test, all 13 Gemfile-test files declare their own rspec / simplecov / simplecov_json_formatter, and nothing else in the job touches root gems (Wait for MongoDB uses nc, Upload coverage reads the artifact).

From the snowflake job log it costs 3.7s per cell (12:49:46.67 → 12:49:50.33), so ~1min30 of runner time across the 24 cells, and it puts ~12MB of never-loaded gems into every one of the 24 caches. Dropping the step would also make the Gemfile and root *.gemspec components of the test cache key redundant.

Two notes in the PR's favour while I was checking:

• bundle exec rubocop --list-target-files at the root already includes every packages/*/Gemfile and packages/*/*.gemspec — RuboCop's default Include covers **/Gemfile. So the accepted regression is narrower than the description states: package Gemfile syntax is still checked, only dependency resolvability is lost. Worth saying, it makes the trade more clearly fine.
• required_status_checks.contexts on main is indeed [], so collapsing the 26 Lint (x, y) contexts cannot wedge PRs.

[christophebrun-forest]

Juste on comment on tests.

Note :
A comment regarding consistency rather than performance: consider adding a group for pull requests specifically to stop them if a new commit is made to the same PR.

[matthv]

Both taken, thanks — the two changes are in the working tree and land with the next push.

The test job's Install dependencies on main repo is gone, and with it the root Gemfile / *.gemspec components of the test cache key, redundant once nothing installs them. Checked your reasoning rather than just taking it: all 12 matrix packages declare rspec + simplecov + simplecov_json_formatter in their own Gemfile-test, and the remaining steps touch no root gem. Then ran the job's real Test step against a BUNDLE_PATH the root Gemfile had never touched — forest_admin_datasource_toolkit resolved 49 gems from Gemfile-test alone, 478 examples, 0 failures, coverage.json written. Your 3.7s/cell figure puts the table's "After" at ~11 min 30 rather than ~13, so I've corrected it.

Concurrency group added, same shape and placement as the one already in security-fixes.yml:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

Conditional rather than plain true on purpose: deploy publishes gems from main/beta, and a run cancelled between two gem push calls would leave a release half-shipped. github.ref is refs/pull/N/merge on a PR, so no cross-PR collision, and notify-ci-failure.yml only fires on branches: [main] — a cancelled PR run can't trip it.

On your Gemfile note — confirmed and folded into the description, which was too pessimistic. bundle exec rubocop --list-target-files at the root lists all 13 packages/*/Gemfile and all 13 gemspecs (26 files), so only dependency resolvability is lost, not syntax. Worth adding that Gemfile-test is not in those 26 — RuboCop's default Include covers **/Gemfile but not that name — so the 12 files the test job actually installs are the ones nothing lints. Small and pre-existing, but it belongs with the release-time install smoke test in the follow-ups.

[christophebrun-forest]

LGTM

[forest-bot]

🎉 This PR is included in version 1.41.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀