baur acts in Git monorepositories. baur locates the root of the repository by searching for the .baur.toml repository configuration file. The directory containing the configuration file is the repository root. All other paths used by baur are relative the repository root.

In the monorepository every application is contained in a single directory. Applications that are managed via baur contain a .app.toml file. The configuration file specifies the build inputs of the application, how the build inputs are converted to build outputs, which build outputs are produced and where they are uploaded to.

Build Inputs are everything that changes the produced build output. This can be source code files, Makefiles that are used to build the application, the docker image in that the application is build, the used compiler, etc.

When the build command is invoked the build inputs are transformed to build outputs, that can be by e.g. compiling .go source code files. baur supports to upload build output files to S3 buckets or copy them to a local directory. Docker image build outputs can be uploaded to Docker registries.

The specified Build Inputs must be complete to ensure that baur can detect than an application changed. If a Build Input is missing, baur won't rebuild the application when the missing Build Input changed. Build Outputs are the artifacts that your build command produces, this can be files or a docker image.

When baur builds an application and uploads their build outputs (baur build), it records the build with the total input digest of the inputs and the uploaded outputs in it's database.

When the next time a baur build is triggered, baur looks up in the database if a build for the application with the same total input digest already exist. If it exist, the application has not changed and the build outputs from the previous build can be used.

baur provides a command called baur verify that finds builds that had the same total input digest but produced outputs with different digests. The command only produces reasonable results when the build artifacts are reproducible. That means that the same build inputs always produce build outputs with the same digests. This is not always trivial to achieve. Tips for achieving it can be found at Debian's Reproducible Builds Howto.

Docker container are never reproducible, their digest always different on a rebuild because already the timestamps of the files in the image change.

The following build statuses are used to describe if an application needs to be rebuild:

• Exist A build with the same input files exist
• Pending No build with the same input file exist, build is necessary
• Inputs Undefined Build Inputs are undefined in the application config