ci: seed codegen image cache from main instead of per-PR scopes

[mishushakov]

Why

generated_files.yml only runs on pull_request, so its cache-to: type=gha,mode=max wrote buildkit blobs into per-PR scopes that other PRs cannot read — every new PR cold-built the codegen image (235–365s in 11 of 17 runs over the past week vs ~65s warm), and ~6 GB of duplicate blobs pushed the repo's Actions cache to 9.9 GB of the 10 GB limit, evicting the Playwright and pnpm caches that #1538 relies on.

What

Adds codegen_image_cache.yml, which builds the image on pushes to main touching its actual inputs (codegen.Dockerfile, packages/connect-python/**, or the workflow itself) and exports the cache to main's scope, readable by all PRs; it also supports workflow_dispatch for manual re-seeding. The PR-side build in generated_files.yml keeps cache-from but drops cache-to. Merging this PR triggers the first seed automatically, since the new workflow file matches its own paths filter.

🤖 Generated with Claude Code

[changeset-bot]

⚠️ No Changeset found

Latest commit: 60132c4

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[cursor]

PR Summary

Low Risk
CI-only workflow changes with no application or security impact; first warm cache appears after the new workflow runs on main.

Overview
Per-PR cache-to on the codegen Docker build in generated_files.yml wrote GitHub Actions cache blobs that other pull requests could not read, so codegen image builds often cold-started and duplicate cache data crowded the repo’s 10 GB limit and evicted caches other workflows depend on.

This adds codegen_image_cache.yml to build codegen.Dockerfile on pushes to main when its inputs change (and via workflow_dispatch) and export cache with cache-to: type=gha,mode=max. The pull request job keeps cache-from: type=gha and removes cache-to.

^{Reviewed by Cursor Bugbot for commit 60132c4. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

Package Artifacts

Built from 9221d29. Download artifacts from this workflow run.

JS SDK (e2b@2.33.1-ci-slow-dependency-installs.0):

npm install ./e2b-2.33.1-ci-slow-dependency-installs.0.tgz

CLI (@e2b/cli@2.13.3-ci-slow-dependency-installs.0):

npm install ./e2b-cli-2.13.3-ci-slow-dependency-installs.0.tgz

Python SDK (e2b==2.32.0+ci.slow.dependency.installs):

pip install ./e2b-2.32.0+ci.slow.dependency.installs-py3-none-any.whl

[claude]

LGTM — straightforward CI cache-seeding change.

Extended reasoning...

Overview

This PR only touches two GitHub Actions workflow files: it adds a new codegen_image_cache.yml that rebuilds the codegen Docker image on pushes to main (when its actual inputs change) and exports the buildkit cache with cache-to: type=gha,mode=max, and it removes the cache-to step from the PR-triggered generated_files.yml job (keeping cache-from) so PRs read the shared main-scoped cache instead of writing their own unreadable per-PR blobs.

Security risks

None. permissions: contents: read is correctly scoped (no registry push, just GHA cache read/write via docker/build-push-action), and the new workflow only triggers on push to main or manual workflow_dispatch, so it cannot be triggered by untrusted PR branches with elevated permissions.

Level of scrutiny

Low — this is a CI-only, non-production change with a clearly stated, verifiable rationale (cache scope isolation causing repeated cold builds and cache eviction). The mechanics (paths filter, cache-from/cache-to split) match standard GitHub Actions + buildkit caching patterns and match the PR description's stated intent exactly.

Other factors

The change is small (2 files, mostly additive), self-contained, and reversible (worst case is a cold-build regression, not a correctness or security issue). No changeset is required since no SDK/CLI packages are touched. No outstanding review comments to address.