MCPcopy Create free account
hub / github.com/vercel/vercel / build

Function build

packages/container/src/index.ts:366–404  ·  view source on GitHub ↗
(options: BuildOptions)

Source from the content-addressed store, hash-verified

364}
365
366export async function build(options: BuildOptions): Promise<BuildResultV2> {
367 const image = await withSpan(
368 options.span,
369 'container.resolve_image',
370 { 'service.name': options.service?.name },
371 span => resolveImageHandler(options, span)
372 );
373
374 const command = normalizeCommand(options.config.command);
375
376 // Do a normal build: the function lands at the natural `index` path and a
377 // catch-all route forwards every request to it. Without it there is no `/`
378 // route, so for a service the top-level service rewrite resolves to nothing
379 // (vercel/vercel#16648), and for a root (non-service) container deploy
380 // nothing reaches the function at all. The filesystem handler resolves `/`
381 // to the `index` output. The only service-specific concern — nesting the
382 // output under `services/<name>/` — is handled by the CLI, not here.
383 const routes = [
384 { handle: 'filesystem' as const },
385 { src: '/(.*)', dest: '/index' },
386 ];
387
388 return {
389 routes,
390 output: {
391 index: {
392 type: 'Lambda',
393 files: {},
394 // For `runtime: 'container'` the OCI image reference is carried in
395 // `handler`; the platform surfaces it as the container image downstream
396 // (vercel/api#76729).
397 handler: image,
398 runtime: 'container',
399 environment: {},
400 ...(command ? { command } : {}),
401 } as any,
402 },
403 };
404}

Callers 3

unit.test.tsFile · 0.90
runDockerfileBuildFunction · 0.90
compileVercelConfigFunction · 0.50

Calls 3

withSpanFunction · 0.90
resolveImageHandlerFunction · 0.85
normalizeCommandFunction · 0.70

Tested by 1

runDockerfileBuildFunction · 0.72