Thank you for your interest in contributing! This document explains our development workflow and guidelines.
We follow GitHub Flow - a simple, branch-based workflow:
┌─────────────────────────────────────────────────────────────┐
│ main branch │
│ (always deployable, protected, requires PR + CI passing) │
└─────────────────────────────────────────────────────────────┘
│ │ │ │
├─feature/A────┤ │ │
│ │ │ │
│ ├─feature/B────┤ │
│ │ │ │
│ │ ├─bugfix/C─────┤
│ │ │ │
▼ ▼ ▼ ▼
v1.0.0 v1.1.0 v1.1.1 v1.2.0
-
Create a feature branch from
maingit checkout main git pull origin main git checkout -b feature/your-feature-name
-
Make your changes and commit
git add . git commit -m "Add feature: description"
-
Push to GitHub
git push origin feature/your-feature-name
-
Create a Pull Request
- Go to GitHub and create a PR from your branch to
main - Fill in the PR template with a clear description
- Link any related issues
- Go to GitHub and create a PR from your branch to
-
CI Pipeline runs automatically
- Linting and code formatting checks
- Build on all platforms (Linux, macOS, Windows)
- Unit tests
- Security scanning (CodeQL, Snyk, Trivy, Gitleaks, Semgrep, etc.)
- Code quality analysis (SonarCloud, Lizard, Valgrind)
-
Address review feedback
- Make requested changes
- Push new commits to your branch
- CI runs again automatically
-
Merge when approved and CI passes
- Squash and merge is preferred for clean history
- Your branch will be automatically deleted
-
Releases are tagged from
main- Maintainers create release tags (e.g.,
v1.0.0) - CI automatically builds and publishes release artifacts
- Maintainers create release tags (e.g.,
- Features:
feature/short-description - Bug fixes:
bugfix/issue-number-description - Hotfixes:
hotfix/critical-issue-description - Documentation:
docs/what-you-are-documenting - Refactoring:
refactor/what-you-are-refactoring
Follow conventional commits format:
type(scope): brief description
Detailed explanation if needed.
Fixes #issue-number
Types:
feat: New featurefix: Bug fixdocs: Documentation changesstyle: Code style changes (formatting, etc.)refactor: Code refactoringtest: Adding or updating testschore: Maintenance tasks, dependency updatesci: CI/CD changes
Examples:
feat(api): add support for multiple restreamer endpoints
fix(config): handle null values in configuration parsing
docs(readme): update installation instructions
All code must pass:
- ✅ clang-format (code formatting)
- ✅ clang-tidy (static analysis)
- ✅ cppcheck (static analysis)
- ✅ Unit tests
- ✅ Security scans (no critical/high vulnerabilities)
- ✅ Complexity check (CCN < 15)
Before submitting your PR, ensure:
- Code follows the project's coding style
- All tests pass locally
- Added tests for new features
- Updated documentation if needed
- Commit messages follow conventions
- No new compiler warnings
- Security scan passes
- PR description clearly explains the changes
See BUILDING.md for detailed build instructions.
Quick start:
# Clone the repository
git clone https://github.com/rainmanjam/obs-polyemesis.git
cd obs-polyemesis
# Install dependencies (Ubuntu/Debian)
sudo apt-get install build-essential cmake libobs-dev libcurl4-openssl-dev libjansson-dev
# Build
cmake -B build -DCMAKE_BUILD_TYPE=Debug -DENABLE_TESTING=ON
cmake --build build
# Run tests
cd build && ctest --output-on-failure
# Local CI/CD testing with act (Linux builds)
act -j ubuntu-build
# Remote Windows testing (requires setup - see docs/developer/WINDOWS_TESTING.md)
./scripts/sync-and-build-windows.sh
./scripts/windows-test.sh
./scripts/windows-package.sh --fetch- 📖 Read the User Guide
- 🐛 Report bugs via GitHub Issues
- 💬 Ask questions in Discussions
Be respectful, inclusive, and constructive in all interactions.
By contributing, you agree that your contributions will be licensed under the same license as the project.