Skip to content

Blubber configuration (v4)

version

.version string (required)

Blubber configuration version. Currently v4.

apt

.apt object

packages

.apt.packages array<string>

Packages to install from APT sources of base image.

For example:

yaml
apt:
  sources:
    - url: http://apt.wikimedia.org/wikimedia
      distribution: buster-wikimedia
      components: [thirdparty/confluent]
  packages: [ ca-certificates, confluent-kafka-2.11, curl ]

packages[]

.apt.packages[] string

apt object

.apt.packages object

Key-Value pairs of target release and packages to install from APT sources.

apt array

.apt.packages.* array<string>

The packages to install using the target release.

*[]

.apt.packages.*[] string

proxies

.apt.proxies array<object|string>

HTTP/HTTPS proxies to use during package installation.

proxies[]

.apt.proxies[] string

Shorthand configuration of a proxy that applies to all sources of its protocol.

proxies[]

.apt.proxies[] object

Proxy for either all sources of a given protocol or a specific source.

source

.apt.proxies[].source string

APT source to which this proxy applies.

url

.apt.proxies[].url string (required)

HTTP/HTTPS proxy URL.

sources

.apt.sources array<object>

Additional APT sources to configure prior to package installation.

APT sources object

.apt.sources[] object

APT source URL, distribution/release name, and components.

components

.apt.sources[].components array<string>

List of distribution components (e.g. main, contrib). See APT repository structure for more information about our use of the distribution and component fields.

components[]

.apt.sources[].components[] string

distribution

.apt.sources[].distribution string

Debian distribution/release name (e.g. buster). See APT repository structure for more information about our use of the distribution and component fields.

url

.apt.sources[].url string (required)

APT source URL.

base

.base null|string

Base image on which the new image will be built; a list of available images can be found by querying the Wikimedia Docker Registry.

builder

.builder object

Run an arbitrary build command.

command

.builder.command array<string>

Command and arguments of an arbitrary build command, for example [make, build].

command[]

.builder.command[] string

requirements

.builder.requirements array<object|string>

Path of files/directories to copy from the local build context. This is done before any of the build steps. Note that there are two possible formats for requirements. The first is a simple shorthand notation that means copying a list of source files from the local build context to a destination of the same relative path in the image. The second is a longhand form that gives more control over the source context (local or another variant), source and destination paths.

Example (shorthand)

yaml
builder:
  command: ["some", "build", "command"]
  requirements: [config.json, Makefile, src/] # copy files/directories to the same paths in the image

Example (longhand/advanced)

yaml
builder:
  command: ["some", "build", "command"]
  requirements:
    - from: local
      source: config.production.json
      destination: config.json
    - Makefile # note that longhand/shorthand can be mixed
    - src/
    - from: other-variant
      source: /srv/some/previous/build/product
      destination: dist/product

requirements[]

.builder.requirements[] string

requirements[]

.builder.requirements[] object

destination

.builder.requirements[].destination string

Destination path. Defaults to source path.

from

.builder.requirements[].from null|string

Variant from which to copy files. Set to local to copy build-context files that match the source pattern, or another variant name to copy files that match the source pattern from the variant's filesystem.

source

.builder.requirements[].source string

Path of files/directories to copy.

builders

.builders array<object>

Multiple builders to be executed in an explicit order. You can specify any of the predefined standalone builder keys (node, python and php), but each can only appear once. Additionally, any number of custom keys can appear; their definition and subkeys are the same as the standalone builder key.

builders[]

.builders[] object

custom

.builders[].custom object

Run an arbitrary build command.

command

.builders[].custom.command array<string>

Command and arguments of an arbitrary build command, for example [make, build].

command[]

.builders[].custom.command[] string

requirements

.builders[].custom.requirements array<object|string>

Path of files/directories to copy from the local build context. This is done before any of the build steps. Note that there are two possible formats for requirements. The first is a simple shorthand notation that means copying a list of source files from the local build context to a destination of the same relative path in the image. The second is a longhand form that gives more control over the source context (local or another variant), source and destination paths.

Example (shorthand)

yaml
builder:
  command: ["some", "build", "command"]
  requirements: [config.json, Makefile, src/] # copy files/directories to the same paths in the image

Example (longhand/advanced)

yaml
builder:
  command: ["some", "build", "command"]
  requirements:
    - from: local
      source: config.production.json
      destination: config.json
    - Makefile # note that longhand/shorthand can be mixed
    - src/
    - from: other-variant
      source: /srv/some/previous/build/product
      destination: dist/product

requirements[]

.builders[].custom.requirements[] string

requirements[]

.builders[].custom.requirements[] object

destination

.builders[].custom.requirements[].destination string

Destination path. Defaults to source path.

from

.builders[].custom.requirements[].from null|string

Variant from which to copy files. Set to local to copy build-context files that match the source pattern, or another variant name to copy files that match the source pattern from the variant's filesystem.

source

.builders[].custom.requirements[].source string

Path of files/directories to copy.

builders[]

.builders[] object

node

.builders[].node object

Configuration related to the NodeJS/NPM environment

allow-dedupe-failure

.builders[].node.allow-dedupe-failure boolean

Whether to allow npm dedupe to fail; can be used to temporarily unblock CI while conflicts are resolved.

env

.builders[].node.env string

Node environment (e.g. production, etc.). Sets the environment variable NODE_ENV. Will pass npm install --production and run npm dedupe if set to production.

requirements

.builders[].node.requirements array<object|string>

Path of files/directories to copy from the local build context. This is done before any of the build steps. Note that there are two possible formats for requirements. The first is a simple shorthand notation that means copying a list of source files from the local build context to a destination of the same relative path in the image. The second is a longhand form that gives more control over the source context (local or another variant), source and destination paths.

Example (shorthand)

yaml
builder:
  command: ["some", "build", "command"]
  requirements: [config.json, Makefile, src/] # copy files/directories to the same paths in the image

Example (longhand/advanced)

yaml
builder:
  command: ["some", "build", "command"]
  requirements:
    - from: local
      source: config.production.json
      destination: config.json
    - Makefile # note that longhand/shorthand can be mixed
    - src/
    - from: other-variant
      source: /srv/some/previous/build/product
      destination: dist/product

requirements[]

.builders[].node.requirements[] string

requirements[]

.builders[].node.requirements[] object

destination

.builders[].node.requirements[].destination string

Destination path. Defaults to source path.

from

.builders[].node.requirements[].from null|string

Variant from which to copy files. Set to local to copy build-context files that match the source pattern, or another variant name to copy files that match the source pattern from the variant's filesystem.

source

.builders[].node.requirements[].source string

Path of files/directories to copy.

use-npm-ci

.builders[].node.use-npm-ci boolean

Whether to run npm ci instead of npm install.

builders[]

.builders[] object

php

.builders[].php object

production

.builders[].php.production boolean

Whether to inject the --no-dev flag into the install command.

requirements

.builders[].php.requirements array<object|string>

Path of files/directories to copy from the local build context. This is done before any of the build steps. Note that there are two possible formats for requirements. The first is a simple shorthand notation that means copying a list of source files from the local build context to a destination of the same relative path in the image. The second is a longhand form that gives more control over the source context (local or another variant), source and destination paths.

Example (shorthand)

yaml
builder:
  command: ["some", "build", "command"]
  requirements: [config.json, Makefile, src/] # copy files/directories to the same paths in the image

Example (longhand/advanced)

yaml
builder:
  command: ["some", "build", "command"]
  requirements:
    - from: local
      source: config.production.json
      destination: config.json
    - Makefile # note that longhand/shorthand can be mixed
    - src/
    - from: other-variant
      source: /srv/some/previous/build/product
      destination: dist/product

requirements[]

.builders[].php.requirements[] string

requirements[]

.builders[].php.requirements[] object

destination

.builders[].php.requirements[].destination string

Destination path. Defaults to source path.

from

.builders[].php.requirements[].from null|string

Variant from which to copy files. Set to local to copy build-context files that match the source pattern, or another variant name to copy files that match the source pattern from the variant's filesystem.

source

.builders[].php.requirements[].source string

Path of files/directories to copy.

builders[]

.builders[] object

python

.builders[].python object

Predefined configurations for Python build tools

no-deps

.builders[].python.no-deps boolean

Inject --no-deps into the pip install command. All transitive requirements thus must be explicitly listed in the requirements file. pip check will be run to verify all dependencies are fulfilled.

poetry

.builders[].python.poetry object

Configuration related to installation of pip dependencies using Poetry.

devel

.builders[].python.poetry.devel boolean

Whether to install development dependencies or not when using Poetry.

version

.builders[].python.poetry.version string

Version constraint for installing Poetry package.

requirements

.builders[].python.requirements array<object|string>

Path of files/directories to copy from the local build context. This is done before any of the build steps. Note that there are two possible formats for requirements. The first is a simple shorthand notation that means copying a list of source files from the local build context to a destination of the same relative path in the image. The second is a longhand form that gives more control over the source context (local or another variant), source and destination paths.

Example (shorthand)

yaml
builder:
  command: ["some", "build", "command"]
  requirements: [config.json, Makefile, src/] # copy files/directories to the same paths in the image

Example (longhand/advanced)

yaml
builder:
  command: ["some", "build", "command"]
  requirements:
    - from: local
      source: config.production.json
      destination: config.json
    - Makefile # note that longhand/shorthand can be mixed
    - src/
    - from: other-variant
      source: /srv/some/previous/build/product
      destination: dist/product

requirements[]

.builders[].python.requirements[] string

requirements[]

.builders[].python.requirements[] object

destination

.builders[].python.requirements[].destination string

Destination path. Defaults to source path.

from

.builders[].python.requirements[].from null|string

Variant from which to copy files. Set to local to copy build-context files that match the source pattern, or another variant name to copy files that match the source pattern from the variant's filesystem.

source

.builders[].python.requirements[].source string

Path of files/directories to copy.

use-system-site-packages

.builders[].python.use-system-site-packages boolean

Whether to inject the --system-site-packages flag into the venv setup command.

version

.builders[].python.version string

Python binary present in the system (e.g. python3).

entrypoint

.entrypoint array<string>

Runtime entry point command and arguments.

entrypoint[]

.entrypoint[] string

lives

.lives object

as

.lives.as string

Owner (name) of application files within the container.

gid

.lives.gid integer

Group owner (GID) of application files within the container.

in

.lives.in string

Application working directory within the container.

uid

.lives.uid integer

Owner (UID) of application files within the container.

node

.node object

Configuration related to the NodeJS/NPM environment

allow-dedupe-failure

.node.allow-dedupe-failure boolean

Whether to allow npm dedupe to fail; can be used to temporarily unblock CI while conflicts are resolved.

env

.node.env string

Node environment (e.g. production, etc.). Sets the environment variable NODE_ENV. Will pass npm install --production and run npm dedupe if set to production.

requirements

.node.requirements array<object|string>

Path of files/directories to copy from the local build context. This is done before any of the build steps. Note that there are two possible formats for requirements. The first is a simple shorthand notation that means copying a list of source files from the local build context to a destination of the same relative path in the image. The second is a longhand form that gives more control over the source context (local or another variant), source and destination paths.

Example (shorthand)

yaml
builder:
  command: ["some", "build", "command"]
  requirements: [config.json, Makefile, src/] # copy files/directories to the same paths in the image

Example (longhand/advanced)

yaml
builder:
  command: ["some", "build", "command"]
  requirements:
    - from: local
      source: config.production.json
      destination: config.json
    - Makefile # note that longhand/shorthand can be mixed
    - src/
    - from: other-variant
      source: /srv/some/previous/build/product
      destination: dist/product

requirements[]

.node.requirements[] string

requirements[]

.node.requirements[] object

destination

.node.requirements[].destination string

Destination path. Defaults to source path.

from

.node.requirements[].from null|string

Variant from which to copy files. Set to local to copy build-context files that match the source pattern, or another variant name to copy files that match the source pattern from the variant's filesystem.

source

.node.requirements[].source string

Path of files/directories to copy.

use-npm-ci

.node.use-npm-ci boolean

Whether to run npm ci instead of npm install.

php

.php object

production

.php.production boolean

Whether to inject the --no-dev flag into the install command.

requirements

.php.requirements array<object|string>

Path of files/directories to copy from the local build context. This is done before any of the build steps. Note that there are two possible formats for requirements. The first is a simple shorthand notation that means copying a list of source files from the local build context to a destination of the same relative path in the image. The second is a longhand form that gives more control over the source context (local or another variant), source and destination paths.

Example (shorthand)

yaml
builder:
  command: ["some", "build", "command"]
  requirements: [config.json, Makefile, src/] # copy files/directories to the same paths in the image

Example (longhand/advanced)

yaml
builder:
  command: ["some", "build", "command"]
  requirements:
    - from: local
      source: config.production.json
      destination: config.json
    - Makefile # note that longhand/shorthand can be mixed
    - src/
    - from: other-variant
      source: /srv/some/previous/build/product
      destination: dist/product

requirements[]

.php.requirements[] string

requirements[]

.php.requirements[] object

destination

.php.requirements[].destination string

Destination path. Defaults to source path.

from

.php.requirements[].from null|string

Variant from which to copy files. Set to local to copy build-context files that match the source pattern, or another variant name to copy files that match the source pattern from the variant's filesystem.

source

.php.requirements[].source string

Path of files/directories to copy.

python

.python object

Predefined configurations for Python build tools

no-deps

.python.no-deps boolean

Inject --no-deps into the pip install command. All transitive requirements thus must be explicitly listed in the requirements file. pip check will be run to verify all dependencies are fulfilled.

poetry

.python.poetry object

Configuration related to installation of pip dependencies using Poetry.

devel

.python.poetry.devel boolean

Whether to install development dependencies or not when using Poetry.

version

.python.poetry.version string

Version constraint for installing Poetry package.

requirements

.python.requirements array<object|string>

Path of files/directories to copy from the local build context. This is done before any of the build steps. Note that there are two possible formats for requirements. The first is a simple shorthand notation that means copying a list of source files from the local build context to a destination of the same relative path in the image. The second is a longhand form that gives more control over the source context (local or another variant), source and destination paths.

Example (shorthand)

yaml
builder:
  command: ["some", "build", "command"]
  requirements: [config.json, Makefile, src/] # copy files/directories to the same paths in the image

Example (longhand/advanced)

yaml
builder:
  command: ["some", "build", "command"]
  requirements:
    - from: local
      source: config.production.json
      destination: config.json
    - Makefile # note that longhand/shorthand can be mixed
    - src/
    - from: other-variant
      source: /srv/some/previous/build/product
      destination: dist/product

requirements[]

.python.requirements[] string

requirements[]

.python.requirements[] object

destination

.python.requirements[].destination string

Destination path. Defaults to source path.

from

.python.requirements[].from null|string

Variant from which to copy files. Set to local to copy build-context files that match the source pattern, or another variant name to copy files that match the source pattern from the variant's filesystem.

source

.python.requirements[].source string

Path of files/directories to copy.

use-system-site-packages

.python.use-system-site-packages boolean

Whether to inject the --system-site-packages flag into the venv setup command.

version

.python.version string

Python binary present in the system (e.g. python3).

runs

.runs object

Settings for things run in the container.

as

.runs.as string

Runtime process owner (name) of application entrypoint.

environment

.runs.environment object

Environment variables and values to be set before entrypoint execution.

gid

.runs.gid integer

Runtime process group (GID) of application entrypoint.

insecurely

.runs.insecurely boolean

Skip dropping of privileges to the runtime process owner before entrypoint execution. Production variants should have this set to false, but other variants may set it to true in some circumstances, for example when enabling caching for ESLint.

uid

.runs.uid integer

Runtime process owner (UID) of application entrypoint.

variants

.variants object

Configuration variants (e.g. development, test, production).

Blubber can build several variants of an image from the same specification file. The variants are named and described under the variants top level item. Typically, there are variants for development versus production: the development variant might have more debugging tools, while the production variant should have no extra software installed to minimize the risk of security issues and other problems.

A variant is built using the top level items, combined with the items for the variant. So if the top level apt installed some packages, and the variant's apt some other packages, both sets of packages get installed in that variant.

variant

.variants.* object

apt

.variants.*.apt object

packages

.variants.*.apt.packages array<string>

Packages to install from APT sources of base image.

For example:

yaml
apt:
  sources:
    - url: http://apt.wikimedia.org/wikimedia
      distribution: buster-wikimedia
      components: [thirdparty/confluent]
  packages: [ ca-certificates, confluent-kafka-2.11, curl ]

packages[]

.variants.*.apt.packages[] string

apt object

.variants.*.apt.packages object

Key-Value pairs of target release and packages to install from APT sources.

apt array

.variants.*.apt.packages.* array<string>

The packages to install using the target release.

*[]

.variants.*.apt.packages.*[] string

proxies

.variants.*.apt.proxies array<object|string>

HTTP/HTTPS proxies to use during package installation.

proxies[]

.variants.*.apt.proxies[] string

Shorthand configuration of a proxy that applies to all sources of its protocol.

proxies[]

.variants.*.apt.proxies[] object

Proxy for either all sources of a given protocol or a specific source.

source

.variants.*.apt.proxies[].source string

APT source to which this proxy applies.

url

.variants.*.apt.proxies[].url string (required)

HTTP/HTTPS proxy URL.

sources

.variants.*.apt.sources array<object>

Additional APT sources to configure prior to package installation.

APT sources object

.variants.*.apt.sources[] object

APT source URL, distribution/release name, and components.

components

.variants.*.apt.sources[].components array<string>

List of distribution components (e.g. main, contrib). See APT repository structure for more information about our use of the distribution and component fields.

components[]

.variants.*.apt.sources[].components[] string

distribution

.variants.*.apt.sources[].distribution string

Debian distribution/release name (e.g. buster). See APT repository structure for more information about our use of the distribution and component fields.

url

.variants.*.apt.sources[].url string (required)

APT source URL.

base

.variants.*.base null|string

Base image on which the new image will be built; a list of available images can be found by querying the Wikimedia Docker Registry.

builder

.variants.*.builder object

Run an arbitrary build command.

command

.variants.*.builder.command array<string>

Command and arguments of an arbitrary build command, for example [make, build].

command[]

.variants.*.builder.command[] string

requirements

.variants.*.builder.requirements array<object|string>

Path of files/directories to copy from the local build context. This is done before any of the build steps. Note that there are two possible formats for requirements. The first is a simple shorthand notation that means copying a list of source files from the local build context to a destination of the same relative path in the image. The second is a longhand form that gives more control over the source context (local or another variant), source and destination paths.

Example (shorthand)

yaml
builder:
  command: ["some", "build", "command"]
  requirements: [config.json, Makefile, src/] # copy files/directories to the same paths in the image

Example (longhand/advanced)

yaml
builder:
  command: ["some", "build", "command"]
  requirements:
    - from: local
      source: config.production.json
      destination: config.json
    - Makefile # note that longhand/shorthand can be mixed
    - src/
    - from: other-variant
      source: /srv/some/previous/build/product
      destination: dist/product

requirements[]

.variants.*.builder.requirements[] string

requirements[]

.variants.*.builder.requirements[] object

destination

.variants.*.builder.requirements[].destination string

Destination path. Defaults to source path.

from

.variants.*.builder.requirements[].from null|string

Variant from which to copy files. Set to local to copy build-context files that match the source pattern, or another variant name to copy files that match the source pattern from the variant's filesystem.

source

.variants.*.builder.requirements[].source string

Path of files/directories to copy.

builders

.variants.*.builders array<object>

Multiple builders to be executed in an explicit order. You can specify any of the predefined standalone builder keys (node, python and php), but each can only appear once. Additionally, any number of custom keys can appear; their definition and subkeys are the same as the standalone builder key.

builders[]

.variants.*.builders[] object

custom

.variants.*.builders[].custom object

Run an arbitrary build command.

command

.variants.*.builders[].custom.command array<string>

Command and arguments of an arbitrary build command, for example [make, build].

command[]

.variants.*.builders[].custom.command[] string

requirements

.variants.*.builders[].custom.requirements array<object|string>

Path of files/directories to copy from the local build context. This is done before any of the build steps. Note that there are two possible formats for requirements. The first is a simple shorthand notation that means copying a list of source files from the local build context to a destination of the same relative path in the image. The second is a longhand form that gives more control over the source context (local or another variant), source and destination paths.

Example (shorthand)

yaml
builder:
  command: ["some", "build", "command"]
  requirements: [config.json, Makefile, src/] # copy files/directories to the same paths in the image

Example (longhand/advanced)

yaml
builder:
  command: ["some", "build", "command"]
  requirements:
    - from: local
      source: config.production.json
      destination: config.json
    - Makefile # note that longhand/shorthand can be mixed
    - src/
    - from: other-variant
      source: /srv/some/previous/build/product
      destination: dist/product

requirements[]

.variants.*.builders[].custom.requirements[] string

requirements[]

.variants.*.builders[].custom.requirements[] object

destination

.variants.*.builders[].custom.requirements[].destination string

Destination path. Defaults to source path.

from

.variants.*.builders[].custom.requirements[].from null|string

Variant from which to copy files. Set to local to copy build-context files that match the source pattern, or another variant name to copy files that match the source pattern from the variant's filesystem.

source

.variants.*.builders[].custom.requirements[].source string

Path of files/directories to copy.

builders[]

.variants.*.builders[] object

node

.variants.*.builders[].node object

Configuration related to the NodeJS/NPM environment

allow-dedupe-failure

.variants.*.builders[].node.allow-dedupe-failure boolean

Whether to allow npm dedupe to fail; can be used to temporarily unblock CI while conflicts are resolved.

env

.variants.*.builders[].node.env string

Node environment (e.g. production, etc.). Sets the environment variable NODE_ENV. Will pass npm install --production and run npm dedupe if set to production.

requirements

.variants.*.builders[].node.requirements array<object|string>

Path of files/directories to copy from the local build context. This is done before any of the build steps. Note that there are two possible formats for requirements. The first is a simple shorthand notation that means copying a list of source files from the local build context to a destination of the same relative path in the image. The second is a longhand form that gives more control over the source context (local or another variant), source and destination paths.

Example (shorthand)

yaml
builder:
  command: ["some", "build", "command"]
  requirements: [config.json, Makefile, src/] # copy files/directories to the same paths in the image

Example (longhand/advanced)

yaml
builder:
  command: ["some", "build", "command"]
  requirements:
    - from: local
      source: config.production.json
      destination: config.json
    - Makefile # note that longhand/shorthand can be mixed
    - src/
    - from: other-variant
      source: /srv/some/previous/build/product
      destination: dist/product

requirements[]

.variants.*.builders[].node.requirements[] string

requirements[]

.variants.*.builders[].node.requirements[] object

destination

.variants.*.builders[].node.requirements[].destination string

Destination path. Defaults to source path.

from

.variants.*.builders[].node.requirements[].from null|string

Variant from which to copy files. Set to local to copy build-context files that match the source pattern, or another variant name to copy files that match the source pattern from the variant's filesystem.

source

.variants.*.builders[].node.requirements[].source string

Path of files/directories to copy.

use-npm-ci

.variants.*.builders[].node.use-npm-ci boolean

Whether to run npm ci instead of npm install.

builders[]

.variants.*.builders[] object

php

.variants.*.builders[].php object

production

.variants.*.builders[].php.production boolean

Whether to inject the --no-dev flag into the install command.

requirements

.variants.*.builders[].php.requirements array<object|string>

Path of files/directories to copy from the local build context. This is done before any of the build steps. Note that there are two possible formats for requirements. The first is a simple shorthand notation that means copying a list of source files from the local build context to a destination of the same relative path in the image. The second is a longhand form that gives more control over the source context (local or another variant), source and destination paths.

Example (shorthand)

yaml
builder:
  command: ["some", "build", "command"]
  requirements: [config.json, Makefile, src/] # copy files/directories to the same paths in the image

Example (longhand/advanced)

yaml
builder:
  command: ["some", "build", "command"]
  requirements:
    - from: local
      source: config.production.json
      destination: config.json
    - Makefile # note that longhand/shorthand can be mixed
    - src/
    - from: other-variant
      source: /srv/some/previous/build/product
      destination: dist/product

requirements[]

.variants.*.builders[].php.requirements[] string

requirements[]

.variants.*.builders[].php.requirements[] object

destination

.variants.*.builders[].php.requirements[].destination string

Destination path. Defaults to source path.

from

.variants.*.builders[].php.requirements[].from null|string

Variant from which to copy files. Set to local to copy build-context files that match the source pattern, or another variant name to copy files that match the source pattern from the variant's filesystem.

source

.variants.*.builders[].php.requirements[].source string

Path of files/directories to copy.

builders[]

.variants.*.builders[] object

python

.variants.*.builders[].python object

Predefined configurations for Python build tools

no-deps

.variants.*.builders[].python.no-deps boolean

Inject --no-deps into the pip install command. All transitive requirements thus must be explicitly listed in the requirements file. pip check will be run to verify all dependencies are fulfilled.

poetry

.variants.*.builders[].python.poetry object

Configuration related to installation of pip dependencies using Poetry.

devel

.variants.*.builders[].python.poetry.devel boolean

Whether to install development dependencies or not when using Poetry.

version

.variants.*.builders[].python.poetry.version string

Version constraint for installing Poetry package.

requirements

.variants.*.builders[].python.requirements array<object|string>

Path of files/directories to copy from the local build context. This is done before any of the build steps. Note that there are two possible formats for requirements. The first is a simple shorthand notation that means copying a list of source files from the local build context to a destination of the same relative path in the image. The second is a longhand form that gives more control over the source context (local or another variant), source and destination paths.

Example (shorthand)

yaml
builder:
  command: ["some", "build", "command"]
  requirements: [config.json, Makefile, src/] # copy files/directories to the same paths in the image

Example (longhand/advanced)

yaml
builder:
  command: ["some", "build", "command"]
  requirements:
    - from: local
      source: config.production.json
      destination: config.json
    - Makefile # note that longhand/shorthand can be mixed
    - src/
    - from: other-variant
      source: /srv/some/previous/build/product
      destination: dist/product

requirements[]

.variants.*.builders[].python.requirements[] string

requirements[]

.variants.*.builders[].python.requirements[] object

destination

.variants.*.builders[].python.requirements[].destination string

Destination path. Defaults to source path.

from

.variants.*.builders[].python.requirements[].from null|string

Variant from which to copy files. Set to local to copy build-context files that match the source pattern, or another variant name to copy files that match the source pattern from the variant's filesystem.

source

.variants.*.builders[].python.requirements[].source string

Path of files/directories to copy.

use-system-site-packages

.variants.*.builders[].python.use-system-site-packages boolean

Whether to inject the --system-site-packages flag into the venv setup command.

version

.variants.*.builders[].python.version string

Python binary present in the system (e.g. python3).

copies

.variants.*.copies array<object|string>

copies[]

.variants.*.copies[] string

Variant from which to copy application and library files. Note that prior to v4, copying of local build-context files was implied by the omission of copies. With v4, the configuration must always be explicit. Omitting the field will result in no COPY instructions whatsoever, which may be helpful in building very minimal utility images.

copies[]

.variants.*.copies[] object

destination

.variants.*.copies[].destination string

Destination path. Defaults to source path.

from

.variants.*.copies[].from null|string

Variant from which to copy files. Set to local to copy build-context files that match the source pattern, or another variant name to copy files that match the source pattern from the variant's filesystem.

source

.variants.*.copies[].source string

Path of files/directories to copy.

entrypoint

.variants.*.entrypoint array<string>

Runtime entry point command and arguments.

entrypoint[]

.variants.*.entrypoint[] string

includes

.variants.*.includes array<string>

Names of other variants to inherit configuration from. Inherited configuration will be combined with this variant's configuration according to key merge rules.

When a Variant configuration overrides the Common configuration the configurations are merged. The way in which configuration is merged depends on whether the type of the configuration is a compound type; e.g., a map or sequence, or a scalar type; e.g., a string or integer.

In general, configuration that is a compound type is appended, whereas configuration that is of a scalar type is overridden.

For example in this Blubberfile:

yaml
version: v4
base: scratch
apt: { packages: [cowsay] }
variants:
  test:
    base: nodejs
    apt: { packages: [libcaca] }

The base scalar will be overwritten, whereas the apt[packages] sequence will be appended so that both cowsay and libcaca are installed in the image produced from the test Blubberfile variant.

includes[]

.variants.*.includes[] string

Variant name.

lives

.variants.*.lives object

as

.variants.*.lives.as string

Owner (name) of application files within the container.

gid

.variants.*.lives.gid integer

Group owner (GID) of application files within the container.

in

.variants.*.lives.in string

Application working directory within the container.

uid

.variants.*.lives.uid integer

Owner (UID) of application files within the container.

node

.variants.*.node object

Configuration related to the NodeJS/NPM environment

allow-dedupe-failure

.variants.*.node.allow-dedupe-failure boolean

Whether to allow npm dedupe to fail; can be used to temporarily unblock CI while conflicts are resolved.

env

.variants.*.node.env string

Node environment (e.g. production, etc.). Sets the environment variable NODE_ENV. Will pass npm install --production and run npm dedupe if set to production.

requirements

.variants.*.node.requirements array<object|string>

Path of files/directories to copy from the local build context. This is done before any of the build steps. Note that there are two possible formats for requirements. The first is a simple shorthand notation that means copying a list of source files from the local build context to a destination of the same relative path in the image. The second is a longhand form that gives more control over the source context (local or another variant), source and destination paths.

Example (shorthand)

yaml
builder:
  command: ["some", "build", "command"]
  requirements: [config.json, Makefile, src/] # copy files/directories to the same paths in the image

Example (longhand/advanced)

yaml
builder:
  command: ["some", "build", "command"]
  requirements:
    - from: local
      source: config.production.json
      destination: config.json
    - Makefile # note that longhand/shorthand can be mixed
    - src/
    - from: other-variant
      source: /srv/some/previous/build/product
      destination: dist/product

requirements[]

.variants.*.node.requirements[] string

requirements[]

.variants.*.node.requirements[] object

destination

.variants.*.node.requirements[].destination string

Destination path. Defaults to source path.

from

.variants.*.node.requirements[].from null|string

Variant from which to copy files. Set to local to copy build-context files that match the source pattern, or another variant name to copy files that match the source pattern from the variant's filesystem.

source

.variants.*.node.requirements[].source string

Path of files/directories to copy.

use-npm-ci

.variants.*.node.use-npm-ci boolean

Whether to run npm ci instead of npm install.

php

.variants.*.php object

production

.variants.*.php.production boolean

Whether to inject the --no-dev flag into the install command.

requirements

.variants.*.php.requirements array<object|string>

Path of files/directories to copy from the local build context. This is done before any of the build steps. Note that there are two possible formats for requirements. The first is a simple shorthand notation that means copying a list of source files from the local build context to a destination of the same relative path in the image. The second is a longhand form that gives more control over the source context (local or another variant), source and destination paths.

Example (shorthand)

yaml
builder:
  command: ["some", "build", "command"]
  requirements: [config.json, Makefile, src/] # copy files/directories to the same paths in the image

Example (longhand/advanced)

yaml
builder:
  command: ["some", "build", "command"]
  requirements:
    - from: local
      source: config.production.json
      destination: config.json
    - Makefile # note that longhand/shorthand can be mixed
    - src/
    - from: other-variant
      source: /srv/some/previous/build/product
      destination: dist/product

requirements[]

.variants.*.php.requirements[] string

requirements[]

.variants.*.php.requirements[] object

destination

.variants.*.php.requirements[].destination string

Destination path. Defaults to source path.

from

.variants.*.php.requirements[].from null|string

Variant from which to copy files. Set to local to copy build-context files that match the source pattern, or another variant name to copy files that match the source pattern from the variant's filesystem.

source

.variants.*.php.requirements[].source string

Path of files/directories to copy.

python

.variants.*.python object

Predefined configurations for Python build tools

no-deps

.variants.*.python.no-deps boolean

Inject --no-deps into the pip install command. All transitive requirements thus must be explicitly listed in the requirements file. pip check will be run to verify all dependencies are fulfilled.

poetry

.variants.*.python.poetry object

Configuration related to installation of pip dependencies using Poetry.

devel

.variants.*.python.poetry.devel boolean

Whether to install development dependencies or not when using Poetry.

version

.variants.*.python.poetry.version string

Version constraint for installing Poetry package.

requirements

.variants.*.python.requirements array<object|string>

Path of files/directories to copy from the local build context. This is done before any of the build steps. Note that there are two possible formats for requirements. The first is a simple shorthand notation that means copying a list of source files from the local build context to a destination of the same relative path in the image. The second is a longhand form that gives more control over the source context (local or another variant), source and destination paths.

Example (shorthand)

yaml
builder:
  command: ["some", "build", "command"]
  requirements: [config.json, Makefile, src/] # copy files/directories to the same paths in the image

Example (longhand/advanced)

yaml
builder:
  command: ["some", "build", "command"]
  requirements:
    - from: local
      source: config.production.json
      destination: config.json
    - Makefile # note that longhand/shorthand can be mixed
    - src/
    - from: other-variant
      source: /srv/some/previous/build/product
      destination: dist/product

requirements[]

.variants.*.python.requirements[] string

requirements[]

.variants.*.python.requirements[] object

destination

.variants.*.python.requirements[].destination string

Destination path. Defaults to source path.

from

.variants.*.python.requirements[].from null|string

Variant from which to copy files. Set to local to copy build-context files that match the source pattern, or another variant name to copy files that match the source pattern from the variant's filesystem.

source

.variants.*.python.requirements[].source string

Path of files/directories to copy.

use-system-site-packages

.variants.*.python.use-system-site-packages boolean

Whether to inject the --system-site-packages flag into the venv setup command.

version

.variants.*.python.version string

Python binary present in the system (e.g. python3).

runs

.variants.*.runs object

Settings for things run in the container.

as

.variants.*.runs.as string

Runtime process owner (name) of application entrypoint.

environment

.variants.*.runs.environment object

Environment variables and values to be set before entrypoint execution.

gid

.variants.*.runs.gid integer

Runtime process group (GID) of application entrypoint.

insecurely

.variants.*.runs.insecurely boolean

Skip dropping of privileges to the runtime process owner before entrypoint execution. Production variants should have this set to false, but other variants may set it to true in some circumstances, for example when enabling caching for ESLint.

uid

.variants.*.runs.uid integer

Runtime process owner (UID) of application entrypoint.