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. Jobs run in parallel where possible; use the aggregate CI check for branch protection.

Job	What it runs
Format check	make format-check
Static check	make static-check
Build and test	make build, make test, make tidy-ci
Coverage	make coverage
Sanitizer	make sanitize
Fuzzer smoke	make fuzzer-smoke
ThreadSanitizer	make tsan
SBOM and dependency audit	make sbom, make dependency-audit

Docs-only pull requests skip build and test jobs but still run format and static checks.

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

Artifacts uploaded on completion include per-job reports under report/ (coverage, sanitize, fuzz, and others).

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
• Line coverage on src/ is ≥ 85% (make coverage)
• DSL changes include fuzz seeds when the parser changes
• User-visible behavior is documented in the wiki and CHANGELOG.md when applicable

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