ci: skip docker image build when unused, harden e2e changes checkout

[arnohillen]

Summary

Two unrelated CI fixes I noticed while debugging slow CI on a 1-line test PR (#59779). Both touch only .github/workflows/, both are easy to revert independently.

1. Skip Build Docker image when no consumer waits for it

container-images-ci.yml's posthog_build runs ~15–25 min on depot-ubuntu-latest-4 and is gated by:

docker_files:
  - '**'
  - '!rust/**'
  - '!livestream/**'

i.e. anything except rust/livestream — basically every PR. But the only consumer of the resulting image is ci-hobby.yml's wait-for-docker-image job (it polls this workflow by check name "Build Docker image" via fountainhead/action-wait-for-check). When ci-hobby would skip — the common case for FE/BE PRs — the build is pure waste.

This PR mirrors ci-hobby.yml's hobby: paths-filter directly into container-images-ci.yml and gates posthog_build on the union of:

• hobby: (matches ci-hobby.yml's hobby: filter — must stay in sync)
• build_self: (changes to the build workflow / build-n-cache-image action)
• hobby-preview PR label
• merge_group (preserved — image still built before merge)

Also adds labeled/unlabeled to the pull_request trigger so adding hobby-preview retroactively kicks off a build (matches ci-hobby.yml's trigger types — without this, the label would arm hobby but never trigger the image build that hobby waits for).

I confirmed the only in-repo consumer is hobby — ci-e2e-playwright.yml and the other "Wait for Docker services" steps use bin/ci-wait-for-docker launch (docker-compose for ephemeral services), not the posthog_build image. Hobby already handles BUILD_CONCLUSION = "skipped" gracefully (ci-hobby.yml line 291–293, exit 0).

Expected impact: ~15–25 min off most FE / BE / docs / test-only PRs.

2. Harden Determine need to run E2E checks against the v6.0.2 promisor-fetch flake

The changes job in ci-e2e-playwright.yml intermittently fails its actions/checkout@v6.0.2 step:

[command]/usr/bin/git checkout --progress --force refs/remotes/pull/59779/merge
##[error]fatal: could not read Username for 'https://github.com': terminal prompts disabled
##[error]fatal: could not fetch <SHA> from promisor remote
##[error]The process '/usr/bin/git' failed with exit code 128

Root cause: filter: blob:none makes the post-fetch git checkout lazy-fetch every blob in HEAD from the promisor remote, and v6.0.2's per-blob credential helper lookup occasionally races with the includeIf-scoped auth file write. Result: any PR can randomly hit a hard BLOCKED merge state until the job is retried (this exact failure on #59779 earlier today).

The job only reads .github/clickhouse-versions.json plus a few git ref operations. Adding sparse-checkout: .github/clickhouse-versions.json collapses the lazy fetch to a single blob — no longer enough surface for the credential issue to manifest, with no impact on the existing fast path.

This is a targeted, surgical fix for the one failing checkout. The same pattern exists in ci-backend.yml and ci-dagster.yml's changes jobs and may want similar treatment if they ever flake — leaving that as a follow-up to keep this PR small.

Test plan

• CI green on this PR. The Build Docker image job should appear as skipped on this PR (workflow-only change, no hobby files touched, no hobby-preview label) — that's the whole point.
• Once merged, on the next FE-only PR (e.g. anything touching frontend/), confirm Build Docker image skips.
• Add the hobby-preview label to a test PR and confirm Build Docker image re-runs.
• Push a Dockerfile change in a follow-up PR and confirm Build Docker image runs.

Out of scope (for follow-up PRs)

• Jest test selection (--findRelatedTests) for ci-frontend.yml — biggest remaining FE win.
• Flipping shadow-story-selection from advisory to authoritative on ci-storybook.yml.
• Tightening frontend_code filter to exclude **/*.test.{ts,tsx} so test-only edits don't trigger bundle-size / typecheck / VR.
• semgrep-* per-language gating (semgrep-js is 3m+ on every PR regardless of touched languages).

Made with Cursor

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
.github/workflows/container-images-ci.yml:5-8
The inline comment claims the two workflows "use the same trigger types" and "stay in lock-step", but `ci-hobby.yml` uses `[opened, synchronize, labeled, unlabeled]` — it does not include `reopened`. As a result, re-opening a PR that touches hobby files will trigger an image build here while ci-hobby never wakes up to consume it, producing a ~15–25 min build that the PR description explicitly aims to eliminate.

```suggestion
        # `labeled`/`unlabeled` lets `hobby-preview` retroactively trigger
        # an image build. Types are kept in sync with ci-hobby.yml; note that
        # ci-hobby.yml does not include `reopened`, so neither does this list.
        types: [opened, synchronize, labeled, unlabeled]
```

_{Reviews (1): Last reviewed commit: "ci: skip docker image build when unused,..." | Re-trigger Greptile}

[gantoine]

But the only consumer of the resulting image is ci-hobby.yml's wait-for-docker-image job

Not sure this is true, ci-e2e-playwright has this comment at the top: This workflow runs CI E2E tests with Playwright. It relies on the container image built by 'container-images-ci.yml'..

[arnohillen]

I see, I'm not an expert in this so happy to close this PR if it doesn't make sense. I made it while waiting for CI to finish :D

[rnegron]

@arnaudhillen in this PR, can we also update ci-e2e-playwright.yml? i dont believe

#
# This workflow runs CI E2E tests with Playwright.
#
# It relies on the container image built by 'container-images-ci.yml'.
#

is correct anymore

[rnegron]

nit: should we add .Dockerignore?

[arnohillen]

Good catch — added .dockerignore to build_inputs: rather than hobby:. .dockerignore changes the build context but doesn't affect hobby's runtime, and hobby: is supposed to mirror ci-hobby.yml's filter byte-for-byte (which doesn't list .dockerignore either).

[arnohillen]

Sorry Cursor replied, but does this make sense?

[webjunkie]

tagging @gantoine since we looked at e2e this week

[gantoine]

assuming these last CI checks pass this looks good

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-05-28 16:34 UTC	Run
prod-us	✅ Deployed	2026-05-28 17:00 UTC	Run
prod-eu	✅ Deployed	2026-05-28 17:02 UTC	Run