Go to file
Peter 364a0e9bab
Some checks failed
continuous-integration/drone/push Build is failing
refactor: make startup more resilient
- add in-memory services for vault and state store
- improve vault security by erasing passphrase on shutdown
- properly handle when project directory wasn't detected
- enable to run many commands even though there's no active project
2023-09-25 15:32:44 +02:00
.buildr refactor: make init logic more lazy and less verbose 2023-09-22 22:35:57 +02:00
.run refactor: use connect-go instead of regular Google gRPC 2023-09-12 18:43:34 +02:00
assets feat: manual for individual modules 2023-06-19 20:19:56 +02:00
internal refactor: make startup more resilient 2023-09-25 15:32:44 +02:00
modules refactor: make startup more resilient 2023-09-25 15:32:44 +02:00
.buildrignore fix(vault): handle salt correctly 2023-04-25 18:14:59 +02:00
.drone.yml feat: add tar and gzip package modules 2023-09-21 13:15:25 +02:00
.editorconfig feat: implement new and man for plugin modules 2023-08-23 22:06:26 +02:00
.gitignore feat: move gRPC code to extra module 2023-08-16 17:34:32 +02:00
.golangci.yml refactor: use connect-go instead of regular Google gRPC 2023-09-12 18:43:34 +02:00
go.mod fix(deps): update module github.com/opencontainers/image-spec to v1.1.0-rc5 2023-09-20 17:23:36 +00:00
go.sum fix(deps): update module github.com/opencontainers/image-spec to v1.1.0-rc5 2023-09-20 17:23:36 +00:00
LICENSE Initial commit 2023-03-13 07:20:24 +00:00
main.go refactor: make init logic more lazy and less verbose 2023-09-22 22:35:57 +02:00
README.md docs(readme): describe basic idea 2023-04-20 11:48:08 +02:00
renovate.json fix(renovate): update config 2023-09-20 19:19:17 +02:00

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:

  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