.buildr | ||
.forgejo/workflows | ||
.run | ||
assets | ||
core | ||
docs | ||
handlers/cli | ||
infrastructure | ||
internal | ||
modules | ||
presentation/tui | ||
.buildrignore | ||
.editorconfig | ||
.gitignore | ||
.golangci.yml | ||
go.mod | ||
go.sum | ||
LICENSE | ||
main.go | ||
README.md | ||
renovate.json |
buildr
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:
- Install tools
- Run some tasks e.g. to generate code, execute tests, ...
- Build your optimized binary
- Package it e.g. as container image or as archive (coming soon)
- 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 viago 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