[so0k]

Refs #206 (GHCR-for-CI half; OCF Public ECR for the devcontainer is a follow-up).

Why

Docker Hub's anonymous pull throttling on GitHub's shared runner IP pool is causing intermittent container-init failures across CI (see the audit in #206). All ~27 container: references across 12 workflows pull terraconstructs/jsii-terraform anonymously; GHCR public-package pulls from Actions runners are free, unmetered, and unauthenticated.

What

• docker.yml: also pushes to ghcr.io/open-constructs/jsii-terraform (packages: write + docker/login-action against ghcr.io with GITHUB_TOKEN). Docker Hub publishing stays until consumers have moved.
• Dockerfile: adds org.opencontainers.image.source label so future pushes auto-link the GHCR package to this repo (plus description/licenses labels).
• 12 consumer workflows: container.image repointed to ghcr.io/open-constructs/jsii-terraform@sha256:c46ac91… — the same digest as today, because the image is mirrored registry-to-registry (digest-preserving). No rebuild needed for this PR's CI to pass.

Prerequisites before marking ready (one-time, maintainer)

• Mirror the current image to GHCR (digest-preserving copy):

  echo $GHCR_TOKEN | docker login ghcr.io -u <user> --password-stdin   # PAT with write:packages
  docker buildx imagetools create \
    --tag ghcr.io/open-constructs/jsii-terraform:latest \
    docker.io/terraconstructs/jsii-terraform@sha256:c46ac91c8be20947a2b0e27a517eb4a5bfc015c16a27341876ed0b04d734ddf5

• Set the new package public (org → Packages → jsii-terraform → settings → Change visibility). New GHCR packages default to private; anonymous CI pulls get 403 until this is done.
• Manually link the package to this repo in package settings (the mirrored manifest predates the source label; the label takes over on the next docker.yml push to main).
• Re-run CI on this PR to confirm GHCR pulls resolve, then mark ready.

Follow-ups (tracked in #206)

• Mirror to OCF Public ECR for devcontainer/contributor distribution; update .devcontainer.json + CONTRIBUTING.md.
• Retire Docker Hub publishing and the DOCKERHUB_* secrets once consumers have moved.

🤖 Generated with Claude Code

[so0k]

migrated the docker hub image to GHCR for this repo

[sakul-learning]

🔒 Cache poisoning risks in workflow changes

This PR is clean and correct in intent, but the docker.yml cache configuration (pre-existing) has two issues worth flagging:

1. Bare restore-keys prefix — cache poisoning vector

https://github.com/open-constructs/cdk-terrain/blob/fix/ghcr-ci-image/.github/workflows/docker.yml#L26-L28

key: ${{ runner.os }}-buildx-${{ hashFiles('/Dockerfile', '.terraform.versions.json') }}
restore-keys: |
  ${{ runner.os }}-buildx-

The restore-keys has no hash suffix — it matches ANY previous buildx cache regardless of Dockerfile or TF version changes. A stale/poisoned cache from a different Dockerfile version can be silently restored, injecting different layers into the build.

Fix: add a hash fallback:

restore-keys: |
  ${{ runner.os }}-buildx-${{ hashFiles('/Dockerfile', '.terraform.versions.json') }}
  ${{ runner.os }}-buildx-

This prefers the exact-hash match but falls back to any buildx cache as a last resort.

2. hashFiles('/Dockerfile') — absolute path may not resolve

The leading / in hashFiles('/Dockerfile', '.terraform.versions.json') is an absolute path. In GHA, hashFiles patterns are typically workspace-relative. If /Dockerfile resolves to nothing, the hash is constant (empty), making all builds share the same cache key — defeating cache isolation.

Fix: use hashFiles('Dockerfile', '.terraform.versions.json') or hashFiles('**/Dockerfile', '.terraform.versions.json').

---

These are pre-existing, not introduced by this PR, but since this PR touches docker.yml it's a good moment to address them.

[so0k]

Thanks for flagging this — addressed in 676fcbd, though with a different fix than the suggested key tightening.

I ran zizmor to pin down the exact rule: it reports the caching as a high-severity cache-poisoning finding, and the trigger is the combination of a GitHub Actions cache feeding a workflow that publishes an image (docker/build-push-action with push: true). Tightening restore-keys or fixing the hashFiles('/Dockerfile') path wouldn't clear it: the Actions cache itself is writable from less-privileged contexts (any branch workflow in the repo can populate entries under the same scope), so however precise the key, a poisoned entry could be baked into the published image. That's why I moved off the GHA cache mechanism entirely rather than patching the key.

Resolution — registry-backed buildx cache:

cache-from: type=registry,ref=ghcr.io/open-constructs/jsii-terraform:buildcache
cache-to: type=registry,ref=ghcr.io/open-constructs/jsii-terraform:buildcache,mode=max

• Writing to :buildcache requires packages: write, which only this workflow's GITHUB_TOKEN has (it runs on push-to-main / workflow_dispatch only; fork PR tokens are read-only and same-repo PRs never run docker.yml) — so no less-privileged context can poison it.
• mode=max exports all intermediate layers, so caching is as good as before. Better, actually: your two observations were spot-on — the absolute hashFiles('/Dockerfile') never resolved and the bare restore-keys prefix matched any prior cache, so the old setup had the poisoning exposure without meaningful cache isolation.
• First run after merge is a cold build that seeds :buildcache; the cache ref shows up alongside the image tags in the GHCR package, which is the standard pattern.

Also set persist-credentials: false on the checkout while in there (zizmor artipacked). zizmor now reports no findings on docker.yml.

[sakul-learning]

Retracting the cache-poisoning concerns from my earlier comment — 676fcbd removes actions/cache entirely and replaces it with registry-backed Buildx cache (cache-from/cache-to: type=registry).

Re-verified at 676fcbd — this is the right approach:

• ✅ actions/cache removed — no GHA-cache poisoning surface at all
• ✅ Registry cache requires packages:write scope, same as the push step — no privilege escalation possible
• ✅ persist-credentials: false on checkout prevents token leakage
• ✅ cache-from: type=registry pulls cache layers from GHCR, cache-to: type=registry,mode=max pushes all layers (not just final image layers) for maximal reuse

First-run cold cache: the :buildcache tag won't exist in GHCR until the first push-to-main after merge. That first build does a full rebuild. Every subsequent run hits the registry cache — which is also available to any branch that has packages:read access to the GHCR package.

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days. This helps our maintainers find and focus on the active issues. If you've found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.