chore(ci): Read clickhouse image from versions json for CI

[tpgilmore]

Problem

The turbo-tests product suite in ci-backend.yml hardcoded its ClickHouse server image (clickhouse/clickhouse-server:26.6.1.1193). Everywhere else in backend CI already derives the image from .github/clickhouse-versions.json, but these two pins were hand-maintained copies. Whenever local dev and hobby were bumped to a new ClickHouse version, the product tests kept running the old image until someone remembered to edit both the canonical workflow and its depot shadow. That is the silent drift the versions file exists to prevent.

Changes

Claude made these changes at my direction. turbo-tests now reads the image from the versions file instead of a literal:

• Added a local_image output to the get_clickhouse_versions job, read from the JSON's local key with the same null guard the existing oldest_supported read uses.
• Pointed both turbo-tests image references at ${{ needs.get_clickhouse_versions.outputs.local_image }} and added get_clickhouse_versions to that job's needs.
• Mirrored the same change into the depot shadow (.depot/workflows/ci-backend.yml) so the shadow-drift check stays green.

-                  CLICKHOUSE_SERVER_IMAGE: clickhouse/clickhouse-server:26.6.1.1193
+                  CLICKHOUSE_SERVER_IMAGE: ${{ needs.get_clickhouse_versions.outputs.local_image }}

Note

local in the versions file is the 3-part tag clickhouse/clickhouse-server:26.6.1, not the 4-part 26.6.1.1193. That is a real rolling tag pointing at the same build today, and the compat matrix already pulls it, so there is no functional change now. From here on the product tests track whatever the versions file says.

How did you test this code?

No new automated tests, since this is CI config. I (Claude) could not run the actual turbo-tests job or a full CI run locally. What I did run:

• bin/hogli lint:workflows (after syncing the flox venv): 6/6 checks pass across 100 workflows.
• YAML parse of both files, plus a grep confirming no hardcoded image pins remain.
• jq -r '.local' .github/clickhouse-versions.json returns clickhouse/clickhouse-server:26.6.1, and I confirmed that tag is real and pullable on Docker Hub.
• Traced the skip path: when get_clickhouse_versions is skipped, the output is empty and docker-compose.dev.yml (which extends base) falls back to base's ${CLICKHOUSE_SERVER_IMAGE:-...} default. turbo-tests runs with always(), so the new needs edge cannot cause it to skip. This matches how the existing oldest_supported_image consumers already behave.

actionlint is not installed locally, so CI owns that check. I verified the needs reference and the output declaration by hand.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

Docs update

No user-facing docs affected.

🤖 Agent context

Autonomy: Human-driven by @tpgilmore (agent-assisted)

Tool: Claude Code (Claude Opus 4.8). I followed the repo's authoring-ci-workflows skill (read its SKILL.md, per the CLAUDE.md requirement for any .github/workflows edit). No other skills applied.

Decisions:

• Read from the JSON's local key rather than adding a new 4-part key. The versions file is already the source of truth and the plan was to move these pins onto its 3-part identifiers, so reusing local keeps one lever instead of two.
• Exposed the value as a get_clickhouse_versions output rather than an inline jq in turbo-tests, to match how oldest_supported_image is already consumed and keep the JSON read in one place.
• Left the skip-path fallback to docker-compose's existing default instead of hardcoding one, since the base default is itself kept current by the version-bump automation, so both paths stay on the promoted version.

This closes a lag where the product-test image had to be updated by hand after each ClickHouse bump. The versions file is populated by the existing infra sync, so pulling from it removes the manual step.

[greptile-apps]

Comments Outside Diff (1)

1. .github/workflows/ci-backend.yml, line 618-624 (link)

   Failed Version Read Still Runs Tests

   When get_clickhouse_versions fails, this job can still run because always() is not paired with a success check for the new dependency. In that state local_image is empty, so the Docker Compose fallback runs product tests against the old default image while the version-read job is already red, which makes the test result misleading and burns CI time.

_{Reviews (1): Last reviewed commit: "chore(ci): Read clickhouse image from ve..." | Re-trigger Greptile}

[trunk-io]

     

View Full Report ↗︎ ⋅ Docs

[tpgilmore]

Comments Outside Diff (1)

1. .github/workflows/ci-backend.yml, line 618-624 (link)
   Failed Version Read Still Runs Tests
   When get_clickhouse_versions fails, this job can still run because always() is not paired with a success check for the new dependency. In that state local_image is empty, so the Docker Compose fallback runs product tests against the old default image while the version-read job is already red, which makes the test result misleading and burns CI time.

Reviews (1): Last reviewed commit: "chore(ci): Read clickhouse image from ve..." | Re-trigger Greptile

The version in the docker-compose file should match this version at all times, in the unlikely event the fallback happens it should still be a valid test scenario.

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-07-15 15:19 UTC	Run
prod-us	✅ Deployed	2026-07-15 15:46 UTC	Run
prod-eu	✅ Deployed	2026-07-15 15:48 UTC	Run