ci(java): split java lane into fast/slow + shared PG sidecar (~3× faster, crash-resistant) - #162
Merged
Conversation
The Java local-ci job took ~10m and intermittently died to runner shutdown/cancel. Two structural fixes: - Split `java` into two parallel jobs: `java-fast` (java+kotlin conformance, ~2-3m — the correctness signal) and `java-slow` (full reactor + docker integration). A cancel/OOM mid-integration no longer kills the fast verdict, and the conformance signal surfaces quickly. ci-local.sh grows `--only java-fast|java-slow`; `--only java` (and a plain local run) still runs both lanes in order, byte-equivalent to before. - Give every integration-running job (ts/python/csharp/java-slow) a shared Postgres SIDECAR instead of each scenario booting its own Testcontainers Postgres (java+kotlin alone booted ~30-40 serial containers — the main wall-clock sink and daemon-contention/crash vector). Each port already honors METAOBJECTS_TEST_PG_URL and CREATEs a per-scenario database. The sidecar publishes 5432 to a DYNAMIC host port so concurrent jobs on the shared self-hosted host never collide. - Skip JaCoCo in the reactor (`-Djacoco.skip=true`): its coverage gate is haltOnFailure=false, so it never fails the build — pure instrumentation overhead for a pass/fail signal. Deliberately NOT adding `-T 1C`: this reactor has a documented shared- render-jar race under parallel module builds (integration-test.sh). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ew1XfYSbEAezxjs9opynAe
dmealing
added a commit
that referenced
this pull request
Sep 8, 2026
The Postgres sidecar is the biggest wall-clock lever in this repo, and it existed only in CI. `local-ci.yml` supplies METAOBJECTS_TEST_PG_URL from its `services:` block, so a hand-run of scripts/ci-local.sh silently fell back to booting a Testcontainers Postgres per scenario — the exact cost PR #162 removed in July. Nothing warned; the run just looked slow, which is indistinguishable from the suite being slow. Measured on this box while verifying one cross-port change: python integration 6m54s -> 11.4s (110 passed) kotlin integration part of a 28-minute --only java lane -> 47.7s (132 passed, 0 containers booted) Whole-estate verification of a five-port change went from ~40 minutes to ~5. `ensure_pg_sidecar` hooks the one choke point every integration lane already passes through (run_integration_for, which gates on `docker info`). It starts — or REUSES — a named container and exports the same URL shape CI uses, including MIGRATE_TS_PG_URL, so migrate-ts's real-Postgres suites run locally instead of self-skipping. Reuse is the point: cold ~6s, warm ~1s, so the second run pays nothing. It also arms one Kotlin test that previously self-skipped with no database (131 -> 132). Three properties are deliberate, two of them learned from prior flakes: * If METAOBJECTS_TEST_PG_URL is already set this is a NO-OP, so CI is byte-identical and an explicit override still wins. * The host port is DYNAMIC (`-p 5432`, read back with `docker port`), never 5432:5432 — this host already runs several Postgres containers and the self-hosted runners share it, so a fixed port collides. * Readiness is POLLED, and required twice, before the URL is exported. Postgres reports ready once during init and then restarts, and the original shared-sidecar mode's missing readiness gate was the dominant flake — the first connect to a transiently-slow sidecar hung to the test timeout. Every failure path degrades to the old behaviour with a warning rather than failing the run: docker refusing to start it, no published port, or readiness not reached in 60s all fall back to per-scenario containers. Integration results are unaffected either way. MO_CI_NO_PG_SIDECAR=1 opts out entirely. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The Java
local-cijob took ~10m and intermittently died to runner shutdown/cancel ("received a shutdown signal / operation was canceled"). Two root causes: (1) it ran the full 14-module reactor + double-conformance + JaCoCo single-threaded, and (2)local-ci.ymlnever wired the shared Postgres sidecar, so java+kotlin integration booted ~30-40 serial Testcontainers Postgres — the main wall-clock sink and, contending on one Docker daemon with the other 3 ports, the crash vector.Changes
javainto two parallel jobs.java-fast(java+kotlin conformance — the correctness signal) andjava-slow(full reactor + docker integration). A cancel/OOM mid-integration no longer kills the fast verdict.ci-local.shgrows--only java-fast|java-slow;--only java(and a plain local run) still runs both lanes in order, byte-equivalent to before.METAOBJECTS_TEST_PG_URLand CREATEs a per-scenario database. The sidecar publishes 5432 to a dynamic host port so concurrent jobs on the shared self-hosted host never collide on a fixed port.-Djacoco.skip=true) — its coverage gate ishaltOnFailure=false, so it's pure instrumentation overhead for a pass/fail signal.-T 1C: this reactor has a documented shared-render-jar race under parallel module builds (integration-test.sh).Verified
Full
workflow_dispatchrun on this branch — all jobs green:Java correctness signal: 10m → <1m. Full Java lane: ~3× faster. Every port benefits from removing the shared-daemon container contention.
🤖 Generated with Claude Code