Bobfile

build type:map

A map holding individual build tasks. Each map key is taken as a task name.

build:task

A build task can be seen as the instructions to build a target or to execute a certain cmd without generating targets. Though the more common case for a task is to generate some kind of target. By default the "cmd" part of a task is only executed if any of the input changed or a target can't be loaded from the cache.

build:
  build:
    input: main.go
    cmd: go build -o run
    target: run
    dependsOn:
      - fmt
  fmt:
    cmd: go fmt ./...

input

type: array, text

Inputs and the task description itself determine when a task is rebuild. It's best to use only a minimum amount of inputs. But it's also ok to start with a * and optimise later.

Some examples:

input: main.go

Block style

input: |-
  main.go

Use ! to ignore files

input: |-
  *
  !.gitignore

If you want to go fancy use globbing, double star (**) syntax is supported.

input: |-
  // match files ending in ".md" in subdirectorys of "dir"
  dir/*/*.md

  // match everything that contains a dot in "dir"
  dir/**/*.*

  // ignore all ".gitignore" files in "dir"
  !dir/**/.gitignore

Ignore will overrule any matched input.

cmd

type: array, text

The "cmd" keyword tells the task which commands to execute. Block style is supported. Under the hood a shell parser is used, so you can use the full power of "sh"

Example:

build:
  hello:
    cmd: echo "Hello World"
  hello-blockstyle:
    cmd: |-
      echo Hello
      echo World
  hello-to-file:
    cmd: |-
      echo "Hello World" > hello
  multiline:
    cmd: |-
      echo "Hello \
      World"

target

type: array, text

A target can be a file, directory or even a docker image. Each file or image created in the "cmd" part should be listed as a target. Targets are stored in a artifact store on your local machine ~/.bobcache/artifacts indexed by the hash of the build inputs and the build description. As long as the input hash doesn't change targets are loaded from the local cache.

Hint: docker images require a local docker registry.

Examples:

Adding a file as target

build:
  build:
    input: main.go
    cmd: go build -o run
    target: run

Mutiline path targets

    ...
    target: |-
      file
      dir/

Another way to define mutiline path targets

    ...
    target:
      path: |-
        file
        dir/

Docker image target

    ...
    target:
      image: postgres

Multiline docker image targets

    ...
    target:
      image: |-
        postgres
        minio/minio

dependsOn

type: array

The "dependsOn" keyword let's you define tasks which have to finish execution before the parent task can start doing it's work.

build:
  build:
    input: main.go
    cmd: go build -o run
    target: run
    dependsOn:
      - taskone
      - tasktwo
  taskone: ...
  tasktwo: ...

You can also depend on build tasks defined in bobfiles in child directorys. Those tasks are prefixed with the relative path to their bob.yaml. To depend on a task name build defined in dirone/ use..

build:
  build:
    ...
    dependsOn:
      - dirone/build

rebuild

type: enum

With the rebuild keyword the default rebuild behaviour can be altered. By default it is set to on-change. It also acceptsalways which tells the task not to take input changes into account, instead it will always execute the task.

dependencies

type: array

Task level dependencies take precedence over dependencies defined in the Bobfile.

run type:map

A map holding individual run tasks. Each map key is taken as a run name.

run:task

The run keyword is used to describe how binary or compose files can be run. It is possible to depend on other run tasks as well as on build tasks. A run assures all dependecies are started or build before doing it's work

type

binary | compose

path

Path to a binary or compose file Defaults to: docker-compose.yaml for run:type: compose

dependsOn

Example:

build:
  build: ...
run:
  binary:
    type: binary
    path: ./run
    dependson:
      - build
      - database
  database:
    type: compose

use-nix

type: boolean

Setting this flag to true enables Nix package management functionality to build packages from dependencies keyword. This will adjust the PATH variable with dependencies from /nix/store before passing it to the internal shell.

dependencies

type: array

The dependencies keyword allows you to add dependencies valid for all tasks in a Bobfile. These dependencies will be downloaded or built with Nix.

Dependencies defined on a build task will take precedence over the ones defined at the Bobfile level. The values from this keyword can be either the package name or a path relative to the bobfile of a .nix file.

Example:

use-nix: true
build:
  run-go-version:
    cmd: go version
    dependencies:
        - go_1_18
dependencies:
  - ginkgo.nix
  - php74