Thanks for contributing.
DAC is a Dashboard-as-Code tool with three main surfaces:
- the Go CLI and backend
- the embedded React frontend
- the dashboard authoring model across YAML, TSX, and the semantic layer
Good contributions usually improve one of those areas while keeping the other two coherent.
- Open an issue first for larger changes, schema changes, or anything that affects the public authoring model.
- Keep pull requests focused. Small, reviewable changes move faster than broad refactors.
- If you change user-facing behavior, update docs and examples in the same pull request.
DAC uses the Bruin CLI for query execution, so install bruin if you want to run live queries locally.
Prerequisites:
- Go 1.25+
- Node.js 20+
make- Bruin CLI on your
PATHfordac serve,dac query, anddac check
Install dependencies:
make depsRun the core verification loop:
make test
make buildRun DAC against an example project:
./bin/dac serve --dir examples/basic-yaml
./bin/dac validate --dir examples/semantic-yaml- Use
makecommands instead of ad-hocgo build,go test, ornpm run build. - Add or update tests for any behavioral change.
- After every change, scan
docs/for areas the change touches and update them in the same PR — add a new doc page if nothing existing fits. - Update one of the curated projects in
examples/if the authoring model changes. - Keep YAML and TSX behavior aligned when a feature exists in both surfaces.
cmd/: CLI commands and flag handlingpkg/dashboard/: dashboard loading, validation, YAML/TSX parsingpkg/semantic/: semantic model loading and SQL compilationpkg/server/: HTTP API and runtime query orchestrationpkg/query/: query execution backendsfrontend/: embedded React frontendexamples/: runnable public sample projectsdocs/: VitePress documentation sourcetestdata/: internal fixtures used by unit tests
Before opening a PR, run:
make test
make buildIf your change affects examples or runtime behavior, also run the relevant example manually:
./bin/dac validate --dir examples/basic-yaml
./bin/dac validate --dir examples/semantic-yamlPRs should include:
- a clear problem statement
- the implementation approach
- any tradeoffs or intentional limitations
- screenshots or short recordings for visible UI changes
- Bugs and feature requests: GitHub issues
- Security reports:
security@getbruin.com - General support questions:
support@getbruin.com