Skip to main content

Description

Build the model defined by the current workspace. The image is built from reactor.yaml’s ‘build:’ block: the Dockerfile is generated in memory and handed straight to BuildKit, never written to the workspace. reactor.yaml must declare build.runtime_version, which names the reactor-runtime release the image installs. A Dockerfile on disk takes the build over. The workspace ./Dockerfile is built verbatim when it exists, and -f/--dockerfile builds an explicit path instead; either way reactor.yaml’s build fields are ignored, with a stderr note naming them. --no-dockerfile builds from reactor.yaml even when a ./Dockerfile exists, and is mutually exclusive with -f/--dockerfile. The result is tagged ‘reactor-local/<name>:dev’ (where <name> is derived from the workspace directory name and sanitized for Docker). This is a local development artifact; ‘reactor model deploy’ builds and publishes its own versioned deployment image. --build-secret forwards a BuildKit secret using docker’s standard ‘--secret’ grammar: comma-separated key=value fields with keys type (file|env), id, src/source, and env - for example ‘id=<id>,src=<path>’, ‘id=<id>,env=<envvar>’, or ‘type=env,id=<id>’. The secret is mounted at /run/secrets/<id> only during a matching ‘RUN --mount=type=secret,id=<id>’ step in the Dockerfile and is never baked into image layers (unlike --build-env, which is). Repeatable. --build-env overrides a build.build_env value from reactor.yaml for this build only: KEY=VALUE pairs, repeatable. A bare KEY (no ’=’) takes its value from the environment and is dropped when it is unset there. A build from reactor.yaml rejects a KEY that build.build_env does not declare, except the args BuildKit predefines: the proxy variables (such as HTTP_PROXY), SOURCE_DATE_EPOCH, and BUILDKIT_* names. --build-env values are kept in the image metadata, so use --build-secret for credentials. Examples:

Options

Global options

See also

  • reactor - The CLI for the Reactor platform