ci: build the prod template on every cluster (foxtrot, juliett, tango)

[devin-ai-integration]

Summary

code-interpreter-v1 is now built on every production cluster — foxtrot, juliett and tango — instead of foxtrot only. Clusters are separate tenancies with separate template registries, so a template built on one does not exist on the others.

The build moves into a reusable workflow, build_prod_template_clusters.yml (workflow_call: target, skip_cache; secrets: inherit), which holds the cluster map once and fans out as a matrix:

plan            -> jq: [{cluster, domain, api_key_secret, production}] filtered by `target`
build-template  -> strategy.matrix.include: fromJSON(needs.plan.outputs.matrix)
                   env: E2B_API_KEY: ${{ secrets[matrix.api_key_secret] }}, E2B_DOMAIN: ${{ matrix.domain }}

Cluster	E2B_DOMAIN	Secret	in all
foxtrot	e2b.dev (was vars.E2B_DOMAIN)	E2B_PROD_API_KEY (existing)	yes
juliett	e2b-juliett.dev	E2B_JULIETT_API_KEY (existing)	yes
tango	e2b-tango.dev	E2B_TANGO_API_KEY — new, must be added before merging	yes
staging	e2b-staging.dev	E2B_STAGING_API_KEY (existing)	no

• release.yml: build-template calls it with target: all; a failed leg on any cluster blocks the release (a missing key fails fast with Missing secret <name> for cluster: <cluster>).
• build_prod_template.yml (manual): target_environment gains all (new default) and tango, and is passed straight through as target; the runtime case that resolved domain/key is gone.
• Concurrency: the release workflow's group drops the -foxtrot suffix (Release-${{ github.ref }}, one release at a time). The per-cluster group Release-${{ github.ref }}-<cluster> is now on the matrix job, so a manual build and a release for the same cluster still serialize while different clusters run in parallel. The suffix could not stay on the release workflow itself: a workflow and one of its own jobs sharing a concurrency group would block each other.

Companion PR for the desktop template: e2b-dev/desktop#260.

Link to Devin session: https://app.devin.ai/sessions/164235e15a6f4e30bbdc3907d388fbc5
Open in Devin Desktop: https://app.devin.ai/desktop/session/164235e15a6f4e30bbdc3907d388fbc5?variant=devin
Requested by: @mishushakov

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[cursor]

Stale comment

Agentic security review found 1 medium issue: dynamic secrets[...] lookup plus secrets: inherit expands the template-build runner’s secret set beyond the intended cluster API key.

  

_{Sent by Cursor Security Agent: Security Reviewer}

[cursor]

🔒 Agentic Security Review
Severity: MEDIUM

The reusable cluster-build job selects the API key with a dynamic secrets lookup (secrets[matrix.api_key_secret]). GitHub cannot statically determine which secrets that expression needs, so the runner receives every secret inherited by the called workflow. Both callers pass secrets: inherit, so the release path now exposes unused high-value credentials (PyPI, Docker Hub, version-bumper private key, Slack webhooks, and other clusters’ API keys) to this job. E2B_API_KEY is also set at job scope, so every step—including third-party actions and pip install—sees it.

Impact: Compromise of any step on a template-build runner (hijacked Action, poisoned pip dependency, or later logging of context) can read the full inherited secret set instead of a single cluster API key.

 

^{Reviewed by Cursor Security Reviewer for commit f8cb5ab. Configure here.}

[cursor]

🔒 Agentic Security Review
Severity: MEDIUM

The reusable cluster-build job selects the API key with a dynamic secrets lookup (secrets[matrix.api_key_secret]). GitHub cannot statically determine which secrets that expression needs, so the runner receives every secret inherited by the called workflow. Both callers pass secrets: inherit, so the release path now delivers unused high-value credentials (PyPI, Docker Hub, version-bumper private key, Slack webhooks, and other clusters’ API keys) to this job. E2B_API_KEY is also set at job scope, so every step—including third-party actions and pip install—sees the selected cluster key.

Impact: Compromise of any step on a template-build runner (hijacked Action, poisoned pip dependency, or later logging of context) can read the full inherited secret set instead of a single cluster API key.

 

^{Reviewed by Cursor Security Reviewer for commit 6bccfc0. Configure here.}