buildr

README

buildr

• Docs (coming soon)
• Raise/vote on feature requests/bug tickets

Current state

The project is currently under heavy development and not production ready (although the project already uses the tool itself to build, run scripts and the like).

Purpose

The general idea is something between goreleaser, taskfile and dagger.

Think of: having one tool to build all the projects your working on no matter if it's Go code, C#, Java, Python or anything else.

The HCL2 based DSL allows you to define the whole build pipeline and to run it either locally or in the CI of your choice. You can use it to:

• ensure local development dependencies are available
• run steps in container images to use the tools installed there
• define build parameters (so you don't have to keep them in mind or fall back to shell scripts)
• more to come

The basic idea of the workflow is like this:

1. Install tools
2. Run some tasks e.g. to generate code, execute tests, ...
3. Build your optimized binary
4. Package it e.g. as container image or as archive (coming soon)
5. Create a GitHub/GitLab/Gitea release and upload created artifacts

Every module can have dependencies to other modules and the execution will be optimized to run as much in parallel as possible. The CLI can be used to execute every kind of module (buildr build, buildr task, ...).

Features

Tools

• go_tool - install tools via go install

Tasks

• script - run scripts

Builds

• go_build - build Go binaries

Packages

• container_image - build container images (no Docker/Podman installation required)

Helpers

• vault to encrypt required secrets and store them as part of your code

Execution

• execute modules locally
• execute modules in a container
  • output is streamed back
  • created files are automatically extracted
• map input for modules
  • allow layering of multiple directories on top of each other (just like container image layers)
  • allow operation on a subdirectory/subset of files of the repository (works for local and container execution environments)
• redirection of created files
  • in container execution environment a filesystem watcher tracks created/modified files, for local task execution a unionfs a-like FUSE driver is used to layer directories and redirect created files to a module specific output directory
  • out_dir of every module is configurable and can be set to repository root if desired
• .buildrignore (same semantics like .gitignore) to exclude files that should never be copied e.g. to/from containers