Tasks
This page reflects the options available in the most recent version of Batect.
Tasks are the smallest unit of work in Batect. They are an operation you can do: compiling your application, running the tests, running a linter or deploying your application.
Names
Task names must meet the following requirements:
they must contain only:
- uppercase or lowercase letters
- digits
- dashes (
-) - periods (
.) - underscores (
_) - colons (
:)
they must start with a letter or digit
they must end with a letter or digit
Definition
Each task definition is made up of the following fields:
At least one of run or prerequisites is required.
run
Specifies what to do when this task starts.
If run is not provided, then prerequisites is required and the tasks listed in prerequisites are run to completion before considering this task complete.
run is made up of the following fields:
container
Container to run for this task. Required.
command
Command to run for this task.
Overrides any command specified on the container definition and the image's default command. If no command is provided here, the command specified on the container definition is used if there is one, otherwise the image's default command is used.
This command is passed to the image's ENTRYPOINT, just like it would when using docker run <image> <command> directly.
This means that if the entrypoint is not set or is not a shell, standard shell syntax features like $MY_ENVIRONMENT_VARIABLE and && might not work.
See the Docker docs for CMD and
ENTRYPOINT for more details.
If you would like to use shell syntax features in your command, you have four options:
Create a shell script and invoke that instead of specifying the command directly.
Wrap your command in a shell invocation.
For example, if your command is
echo hello && echo world, setcommandtosh -c 'echo hello && echo world'.Set the entrypoint in the image to a shell. For example:
DockerfileENTRYPOINT ["/bin/sh", "-c"]Set the entrypoint for the container to a shell. For example:
batect.ymlcontainers:
container-1:
command: "'echo hello && echo world'"
entrypoint: /bin/sh -c(the
commandabove is enclosed in single quotes so that whole command is treated as a single argument when passed tosh, and then enclosed in double quotes so that YAML preserves the single quotes)
Note that for both options 3 and 4, you must quote the command so that it is passed to sh -c as a single argument (we want the final command line to be sh -c 'echo hello && echo world', not
sh -c echo hello && echo world).
entrypoint
Entrypoint to use to run the command.
Overrides any entrypoint specified on the container definition and the image's default entrypoint. If no entrypoint is provided here, the entrypoint specified on the container definition is used if there is one, otherwise the image's default entrypoint is used.
Applies to whichever command takes precedence, whether that is the command specified on this task, the command specified on the container, or the image's default command.
environment
List of environment variables (in name: value format) to pass to the container, in addition to those defined on the container itself.
If a variable is specified both here and on the container itself, the value given here will override the value defined on the container.
Values can be expressions.
ports
List of port mappings to create for the container, in addition to those defined on the container itself.
Behaves identically to specifying a port mapping directly on the container, and supports the same syntax.
working_directory
Working directory to use for this task's container.
Overrides any working directory on the container definition and the image's default working directory. If no working directory is provided here, the working directory specified on the container definition is used if there is one, otherwise the image's default working directory is used.
prerequisites
List of other tasks that should be run to completion before running this task. Names are case-sensitive.
If a prerequisite task finishes with a non-zero exit code, then neither this task nor any other prerequisites will be run.
The tasks are run in the same order that they are declared in, unless reordering is required to satisfy the prerequisites of this task's prerequisites. If a task is listed explicitly and also matches a wildcard, the first occurrence of the task is used.
Passing the --skip-prerequisites command line flag skips all defined prerequisites and runs only the task specified on the command line.
Wildcards
Prerequisite names can include wildcards, denoted by *. For example, rather than listing lint:bar and lint:foo, you can give just lint:*, and Batect will automatically run both lint:bar and
lint:foo.
A single * matches zero or more characters. For example, giving lint:* as a prerequisite would match the tasks lint:a, lint:foo and lint:.
To avoid YAML syntax issues with * characters, it's recommended you enclose names containing wildcards in quotes (eg. use "lint:*" rather than lint:*).
If a wildcard matches multiple tasks, the tasks are returned in alphabetic order. If a wildcard does not match any tasks, no error is raised.
customise
Customisations to apply to containers started as part of this task.
Customisations can modify the working directory used by a container, add or override environment variables, or expose additional ports.
Customisations can apply to containers listed as a dependency directly on the task or on another container.
Customisations cannot be applied to the main task container specified with container. Use the corresponding fields on run instead.
Customisations do not apply to containers started as part of prerequisite tasks.
Example
In the example below, running the build task will start both main-container and container-a. container-a will run with the following configuration:
Working directory:
/customisedExposed ports: both
1000:2000and3000:4000CONTAINER_VAR:set on containerOVERRIDDEN_VAR:overridden value from taskNEW_VAR:new value from task
containers:
main-container:
image: ...
container-a:
image: ...
environment:
CONTAINER_VAR: set on container
OVERRIDDEN_VAR: won't be used
working_directory: /wont-be-used
ports:
- 1000:2000
tasks:
build:
dependencies:
- container-a
run:
container: build-env
customise:
container-a:
working_directory: /customised
environment:
OVERRIDDEN_VAR: overridden value from task
NEW_VAR: new value from task
ports:
- 3000:4000
environment
List of environment variables (in name: value format) to pass to the container, in addition to those defined on the container itself.
If a variable is specified both here and on the container itself, the value given here will override the value defined on the container.
Values can be expressions.
ports
List of port mappings to create for the container, in addition to those defined on the container itself.
Behaves identically to specifying a port mapping directly on the container, and supports the same syntax.
working_directory
Override the working directory used by the container.
Takes precedence over the working directory specified on the container definition (if any) and the default working directory in the image.
dependencies
List of other containers (not tasks) that should be started and healthy before starting the task container given in run, in addition to those defined on the container itself.
The behaviour is the same as if the dependencies were specified for the dependencies on the main task container's definition.
description
Description shown when running batect --list-tasks.
group
Group name used to group tasks when running batect --list-tasks.
Examples
For more examples and real-world scenarios, take a look at the sample projects.
Minimal configuration
tasks:
start-app:
run:
container: app
Running the task start-app will start the app container.
The container will run the command provided in the container configuration (or the default command in the image if there is no command given for the container definition).
Task with prerequisites
tasks:
build:
run:
container: build-env
command: build.sh
start-app:
run:
container: app
prerequisites:
- build
Running the task start-app will first run the build task (which runs build.sh in the build-env container), and then run the app container.
If the command build.sh exits with a non-zero exit code, start-app will not be run.
Task with dependencies
tasks:
start-app:
run:
container: app
dependencies:
- database
- auth-service-fake
Running the task start-app will do the following:
Build or pull the images for the
app,databaseandauth-service-fakecontainers, as appropriateStart the
databaseandauth-service-fakecontainersWait for the
databaseandauth-service-fakecontainers to report themselves as healthy (if they have health checks defined)Start the
appcontainer
Task with environment variables
tasks:
start-app:
run:
container: app
environment:
COUNTRY: Australia
SUPER_SECRET_VALUE: $SECRET_PASSWORD
ANOTHER_SECRET_VALUE: ${SECRET_PASSWORD}
OPTIMISATION_LEVEL: ${HOST_OPTIMISATION_LEVEL:-none}
Running the task start-app will start the app container with the following environment variables:
The environment variable
COUNTRYwill have valueAustralia.The environment variables
SUPER_SECRET_VALUEandANOTHER_SECRET_VALUEwill have the value of theSECRET_PASSWORDenvironment variable on the host. (So, for example, ifSECRET_PASSWORDisabc123on the host, thenSUPER_SECRET_VALUEwill have the valueabc123in the container.)If
SECRET_PASSWORDis not set on the host, Batect will show an error message and not start the task.The environment variable
OPTIMISATION_LEVELwill have the value of theHOST_OPTIMISATION_LEVELenvironment variable on the host.If
HOST_OPTIMISATION_LEVELis not set on the host, thenOPTIMISATION_LEVELwill have the valuenonein the container.
Task with port mappings
tasks:
start-app:
run:
container: app
ports:
- 123:456
- local: 1000
container: 2000
Running the task start-app will start the app container with the following port mappings defined:
- Port 123 on the host will be mapped to port 456 inside the container
- Port 1000 on the host will be mapped to port 2000 inside the container
For example, this means that if a web server is listening on port 456 within the container, it can be accessed from the host at http://localhost:123.
The Dockerfile for the image used by the app container does not need to contain an EXPOSE instruction for ports 456 or 2000.
Note that this does not affect how containers launched by Batect as part of the same task access ports used by each other, just how they're exposed to the host.
Any container started as part of a task will be able to access any port on any other container at the address container_name:container_port. For example,
if a process running in another container wants to access the application running on port 456 in the app container, it would access it at app:456,
not app:123