Submitting Changes

Submitting Changes

Before you open a PR

1. Branch from main
2. Implement vertically with tests (see Feature Development Workflow)
3. Run the full local pipeline:

make all

4. Ensure new source and test files are registered in CMake

Optional local CI reproduction:

STRICT_CI=1 ./scripts/ci.sh

Pull request expectations

A good PR includes:

• What changed and why (user-visible behavior or bug fixed)
• How it was tested (new/updated tests, manual steps if any)
• The feature checklist from Feature Development Workflow when applicable
• No unrelated drive-by refactors mixed into functional changes

Keep commits focused. The repository does not require a specific commit message format, but messages should describe intent, not only file names.

Continuous integration

GitHub Actions workflow Quality Assurance (.github/workflows/ci.yml) runs on pushes and PRs to main:

Step	Make target
Build	make build
Tests	make test
Format	make format-check
Lint	make lint
Static analysis	make analyze
Security	make security
Coverage	make coverage
Sanitizers	make sanitize
Fuzzer	make fuzzer-smoke

Environment: Ubuntu 24.04, Clang (LLVM 22 in CI), Conan 2, Ninja.

Artifacts uploaded on completion:

• coverage-report from report/coverage/
• qa-reports from entire report/

A separate CodeQL workflow analyzes C++ on pushes to main and develop, on pull requests targeting main, and on a weekly schedule.

Definition of done

A change is ready to merge when:

• All CI checks pass
• make all passes locally (or discrepancies are explained)
• Tests cover new behavior including failure paths where relevant
• DSL changes include fuzz seeds when the parser changes
• Public behavior is reflected in the wiki when user-facing (optional but appreciated for larger features)

Code style

• C++20, extensions off (CMAKE_CXX_EXTENSIONS OFF)
• clang-format for C++ and headers
• cmake-format for CMake files
• clang-tidy warnings treated seriously in lint/analyze targets
• Prefer matching existing naming and module boundaries in touched files

Reporting issues

When filing bugs, include:

• Beez version or commit hash
• OS and compiler version
• Minimal build.lua or steps to reproduce
• Expected vs actual behavior
• Relevant log output (--verbose, run log path)

License

Contributions are accepted under the project Apache-2.0 license. You must have the right to submit the code you contribute.

Related pages

• Development and Contribution - chapter index
• Code Quality - local QA commands
• Building and Setup - environment setup