Follow-up to #1632, which added the template this depends on. Now
rebased onto `main`, so this is just the test change.
## Problem
The firewall transform tests asserted header injection by curling
`httpbin.e2b.team`, an externally hosted service the suite had to keep
alive.
## Fix
Starts a sidecar sandbox from the `httpbin` template instead: the rule
is keyed on the sidecar's `getHost(8080)` and the assertion reads the
injected header back from `/headers`, in the JS, sync Python, and async
Python suites. The sidecar's ready command has already passed by the
time `create` resolves, so the server is serving and no readiness
polling is needed. The template name lives in one fixture per SDK —
`httpbinTemplate` in `tests/template.ts` and the `httpbin_template`
fixture in `conftest.py`.
Also drops two comments merged in #1632 that claimed the tests spawn
`e2b/httpbin`. The bare alias is what resolves, same as `base` — the
team slug only appears in the display name.
⚠️ Do not merge before **Build and push prepared templates** has been
dispatched with `template: httpbin` — the tests resolve the template by
name and fail until it exists on the E2B team.
Verified against production: all three tests pass with the injected
header reflected by the sidecar, spawning the template by its bare alias
with a key that owns it — the same situation as CI.
SDK-304
Co-authored-by: Claude <noreply@anthropic.com>
## Problem
The firewall transform tests assert header injection by curling
`httpbin.e2b.team`, an externally hosted service the suite has to keep
alive. Transforms are applied by the egress proxy on the way *out* of a
sandbox, so the target has to be publicly reachable — which rules out a
CI service container, but not another sandbox.
## Change
Adds a `httpbin` template (`templates/httpbin`): go-httpbin on
`debian:bookworm-slim`, SHA256-pinned against the release
`checksums.txt` the way `templates/base` pins its Node install. Neither
official image can serve as an E2B base — `ghcr.io/mccutchen/go-httpbin`
is distroless (no shell, and `dockerfileParser.ts:79` rejects
multi-stage so the binary can't be copied out), and
`kennethreitz/httpbin` is Ubuntu 18.04 whose build fails on E2B's
`fuse3` install (both verified by building).
`templates.yml` gains a `template` choice input (`all` / `base` /
`httpbin`) rather than a second near-identical workflow file. `all` is
the default so a plain dispatch behaves as before, and the DockerHub
image job is skipped for `httpbin`, which has no image counterpart.
The template stays **private to the E2B team**, like `base` — publishing
would only expose it to other projects, and the tests that spawn it use
our API key anyway. The alias is passed unprefixed because the server
namespaces it with the team slug, so the name the tests resolve is
**`e2b/httpbin`**; only `base` predates namespacing and stays bare.
Merge this, then dispatch **Build and push prepared templates** with
`template: httpbin` — #1631 stacks on top and resolves the template as
`e2b/httpbin`.
<sub>Stack created with <a
href="https://github.com/github/gh-stack">GitHub Stacks CLI</a> • <a
href="https://gh.io/stacks-feedback">Give Feedback 💬</a></sub>
SDK-304
Co-authored-by: Claude <noreply@anthropic.com>
Adds a `buildTemplate` CI job that builds and publishes the `base`
template through the e2b CLI, running alongside the existing DockerHub
image push (renamed to `buildAndPushImage`). For security, the CLI is
built from source in this repo rather than installing the published
`@e2b/cli` package; this build-and-global-install logic lives in a
reusable composite action at `.github/actions/build-cli` so it can be
shared across workflows. Removes the static `templates/base/e2b.toml`
since template config is now driven by the CLI invocation, and switches
the Dockerfile's `node` user/group creation to system accounts (`-r`).
## Usage
Any workflow can build and install the CLI globally with a single step:
```yaml
steps:
- uses: actions/checkout@v4
- uses: ./.github/actions/build-cli
- run: e2b template create base --memory-mb 512
```
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The Yarn GPG key (6A010C5166006599AA17F08146C2130DFD2497F5) can no
longer be fetched from keyservers, it returns "no user ID". So the
signature verification fails. So let's just download yarn via npm and
simplify this.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Low Risk**
> Build-only change confined to the Dockerfile; main risk is potential
reproducibility/supply-chain differences from switching Yarn
installation method.
>
> **Overview**
> Updates `templates/base/e2b.Dockerfile` to install Yarn via `npm
install -g yarn@1.22.19` instead of downloading and GPG-verifying the
Yarn tarball, removing the keyserver dependency and associated
verification steps.
>
> Also normalizes the Node version env var syntax from `ENV NODE_VERSION
20.9.0` to `ENV NODE_VERSION=20.9.0`.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
243ce4b47da851e3faf64e2329016ef7a9681632. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
Mish Ushakov