Files
hyperframes/packages/cli/tsup.config.ts
T
James RussoandClaude Opus 4.8 4da567df22 feat(gcp-cloud-run): Google Cloud Run + Workflows distributed render adapter (#1253)
* feat(gcp-cloud-run): add Google Cloud Run + Workflows distributed render adapter

Adds @hyperframes/gcp-cloud-run, the GCP counterpart to @hyperframes/aws-lambda
(issue #932). The OSS distributed primitives (plan, renderChunk x N, assemble)
are unchanged; this package is the storage/compute/orchestration glue.

Package: Cloud Run handler (one image, three actions), runs under bun; GCS
transport; in-image chrome-headless-shell resolver; client SDK
(renderToCloudRun, getRenderProgress, deploySite, computeRenderCost); Dockerfile;
Cloud Workflows definition; Terraform module; CLI cloudrun
deploy|sites|render|render-batch|progress|destroy with --output-resolution and
--strict-variables; 62 unit tests + docs + live smoke script.

Shared extraction (removes ~640 lines of adapter duplication): move the
cloud-agnostic config validator + content-hash into producer/distributed; both
adapters import them. Validated end-to-end on GCP at 37.4 dB PSNR vs baseline.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(cli): resolve @hyperframes/gcp-cloud-run in the CLI build + root build

The CLI bundle (esbuild) couldn't resolve `@hyperframes/gcp-cloud-run/sdk`,
failing Build/Typecheck/CLI-smoke (and the perf/windows/regression jobs that
build first). Mirror the aws-lambda handling: mark the gcp adapter + its /sdk
subpath external in tsup.config.ts with a source alias, and add gcp-cloud-run
to the root `build` filter so its dist exists for publish + runtime.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(ci): copy gcp-cloud-run manifest in Dockerfile.test for frozen install

The regression test image runs `bun install --frozen-lockfile` after copying
each workspace package.json individually. The CLI now depends on
@hyperframes/gcp-cloud-run (workspace:*), so the frozen install fails to
resolve it unless its manifest is present. Add the COPY line.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* feat(cli): add machine-sizing flags to `cloudrun deploy`

Closes the parity gap with `lambda deploy` (which exposes --memory etc.).
`cloudrun deploy` now threads --cpu, --memory, --max-instances, and --timeout
into the Terraform apply; omitted flags keep the module defaults
(4 vCPU / 16Gi / 100 instances / 3600s). For finer control, apply the module
directly.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(gcp-cloud-run): address PR review (security, waste, limits, alerts)

- server.ts: bucket-allowlist guard no longer fails open silently. Unset env
  logs a one-time WARNING; "*" is an explicit opt-out; otherwise it enforces.
- server.ts: stop double-shipping audio.aac. It already rides in the plan
  tarball every consumer downloads, so drop the redundant standalone upload
  (plan) + re-download/overwrite (assemble); assemble reads it from the untar,
  falling back to a supplied AudioGcsUri for compat.
- server.ts: chunk extension via path.extname() instead of slice(lastIndexOf).
- workflow.yaml: clamp parallel concurrency_limit to math.min(chunkCount, 20)
  — Cloud Workflows hard-caps concurrent iterations at 20.
- Dockerfile: pin bun (bun-v1.3.9) so an interop change can't silently break
  the image rebuild.
- terraform: add min_instances var (default 0); add a workflow-failure alert
  (finished_execution_count status=FAILED) alongside the request-count one.
- costAccounting: document that displayCost excludes GCS storage/egress.

Verified against the actual APIs: @google-cloud/workflows@4.4.0
ICreateExecutionRequest has no executionId (so the idempotency-token suggestion
isn't available in this client); Workflows concurrency cap is 20; failure
metric is workflows.googleapis.com/finished_execution_count (status label).
174 adapter tests pass, fallow/oxlint/oxfmt/terraform clean.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(gcp-cloud-run): address round-2 review — error code + CFR forwarding

- workflow.yaml: rename the zero-chunk failure code PLAN_TOO_LARGE →
  PLAN_PRODUCED_ZERO_CHUNKS. The old code implied a size-ceiling breach (the
  opposite cause), misleading anyone triaging the alert.
- workflow.yaml: forward Config.cfr to the assemble step
  (`Cfr: ${("cfr" in config) and config.cfr}`). It was read by the handler
  but never sent, so exact-CFR was silently off for every Cloud Run render.
  Uses the same `in`-operator guard already proven in the retryable predicate.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(release): include gcp-cloud-run in set-version PACKAGES list

set-version.ts (driven by release:prepare) bumps an explicit package list to
the shared version on each release. gcp-cloud-run was wired into the build +
publish.yml but missing here, so a release would leave it at a stale version
and publish.yml would push the wrong version. Add it so the new package
version-bumps + publishes in lockstep with the others.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-07 14:43:38 -07:00

115 lines
4.8 KiB
TypeScript

import { defineConfig } from "tsup";
import { resolve } from "node:path";
import { readFileSync } from "node:fs";
const pkg = JSON.parse(readFileSync(new URL("./package.json", import.meta.url), "utf-8")) as {
version: string;
};
export default defineConfig({
// hf#732 lever-4: emit BOTH the CLI bundle and the PNG decode + alpha-blit
// worker entry. The producer's `pngDecodeBlitWorkerPool` instantiates a
// Node `worker_threads` Worker via `new Worker(<path>)`, which is a
// filesystem load — it cannot share the parent module graph. The pool's
// path resolver probes for `pngDecodeBlitWorker.js` next to its own loaded
// module (which lives inside `dist/cli.js` after the producer is
// `noExternal`'d and bundled in). Without this entry the file would not
// exist at runtime and the pool would either crash or silently fall back
// to inline decode/blit, killing the perf gain.
entry: {
cli: "src/cli.ts",
pngDecodeBlitWorker: "../producer/src/services/pngDecodeBlitWorker.ts",
// hf#677/#732: shader-blend worker. Same `new Worker(<path>)`
// bundling rationale as `pngDecodeBlitWorker` above.
shaderTransitionWorker: "../producer/src/services/shaderTransitionWorker.ts",
},
format: ["esm"],
outDir: "dist",
target: "node22",
platform: "node",
bundle: true,
splitting: false,
sourcemap: false,
clean: true,
banner: {
js: `import { createRequire as __hf_createRequire } from "node:module";
import { fileURLToPath as __hf_fileURLToPath } from "node:url";
import { dirname as __hf_dirname } from "node:path";
var require = __hf_createRequire(import.meta.url);
var __filename = __hf_fileURLToPath(import.meta.url);
var __dirname = __hf_dirname(__filename);`,
},
external: [
"puppeteer-core",
"puppeteer",
"@puppeteer/browsers",
"open",
"hono",
"hono/*",
"@hono/node-server",
"adm-zip",
"esbuild",
"giget",
"postcss",
// aws-lambda transitively pulls @aws-sdk/* + @smithy/* which include
// .browser.js conditional exports esbuild can't bundle cleanly into
// a node binary. Keep it external; the lambda subverb files dynamic-
// import it only when the user runs `hyperframes lambda *`, so the
// CLI's cold start doesn't load it. Runtime resolution comes from
// @hyperframes/aws-lambda being a `dependencies` entry in package.json.
"@hyperframes/aws-lambda",
"@hyperframes/aws-lambda/sdk",
// Same treatment for the GCP adapter: the cloudrun subverb files
// dynamic-import `@hyperframes/gcp-cloud-run/sdk` only when the user runs
// `hyperframes cloudrun *`. Keep it external; runtime resolution comes
// from the `dependencies`/workspace entry, not the bundled CLI.
"@hyperframes/gcp-cloud-run",
"@hyperframes/gcp-cloud-run/sdk",
],
noExternal: [
"@hyperframes/core",
"@hyperframes/producer",
"@hyperframes/engine",
"@clack/prompts",
"@clack/core",
"picocolors",
"linkedom",
"sisteransi",
"is-unicode-supported",
"citty",
],
define: {
__CLI_VERSION__: JSON.stringify(pkg.version),
},
esbuildOptions(options) {
options.alias = {
"@hyperframes/producer": resolve(__dirname, "../producer/src/index.ts"),
// esbuild's alias map treats `@hyperframes/producer` as a file path
// and would otherwise resolve `@hyperframes/producer/distributed`
// to `../producer/src/index.ts/distributed` (treating the file as a
// directory). Adding an explicit alias for every subpath we import
// avoids the prefix-substitution misfire.
"@hyperframes/producer/distributed": resolve(__dirname, "../producer/src/distributed.ts"),
// Same reason: the lambda CLI imports `@hyperframes/aws-lambda/sdk`,
// which would resolve to `../aws-lambda/src/index.ts/sdk` without
// an explicit subpath alias. The SDK subpath has its own barrel.
"@hyperframes/aws-lambda/sdk": resolve(__dirname, "../aws-lambda/src/sdk/index.ts"),
// Same for the GCP adapter's SDK subpath barrel.
"@hyperframes/gcp-cloud-run/sdk": resolve(__dirname, "../gcp-cloud-run/src/sdk/index.ts"),
// hf#732 lever-4: alias for the PNG decode+blit worker's import.
// `alphaBlit.ts` is import-free (only zlib) so the worker survives
// the worker_thread loader boundary directly via this TS source.
"@hyperframes/engine/alpha-blit": resolve(__dirname, "../engine/src/utils/alphaBlit.ts"),
// hf#677 follow-up: the shader-blend worker imports from
// `@hyperframes/engine/shader-transitions` (subpath export) — a
// standalone TS file with zero internal imports that survives the
// worker_thread loader boundary.
"@hyperframes/engine/shader-transitions": resolve(
__dirname,
"../engine/src/utils/shaderTransitions.ts",
),
};
options.loader = { ...options.loader, ".browser.js": "text" };
},
});