Project & ReleaseGuidelines

Contributing Guide

Code standards, Doxygen requirements, test coverage guidelines, and pull request rules.

5 min read|Updated August 2026

C++ Code Standards & Formatting#

Formatting: All C/C++ code must conform to the project .clang-format definition.
Build Directory Naming: Prefix all build directories with cmake-build- (e.g. cmake-build-release).
Localization: Update only en.json (src_assets/common/assets/web/public/assets/locale/en.json). Do not edit other language variants.

Doxygen Documentation Requirements#

All classes, structs, functions, and member variables must have Doxygen comments or the build will fail (BUILD_WERROR=ON):

Primary function/struct blocks:

cpp

/**
 * @brief Brief summary of the function.
 * @param param_name Parameter description.
 * @return Return value description.
 */

Inline member variables must use ///< ... format (never /**< ... */):

cpp

int latency_mode = 0;  ///< Latency mode: 0 for safe, 1 for aggressive

Test Coverage & Verification#

Always add unit tests in tests/unit/ for new or modified functionality using GoogleTest (gtest). Target 100% test coverage on changed code.

bash

cmake --build cmake-build-release --target test_sunshine -j$(nproc)
./cmake-build-release/tests/test_sunshine --gtest_brief=1

Fork Boundary & Upstream Policy#

Important

Do not open issues or pull requests in the upstream LizardByte GitHub organization for SolarFlare fork work. Submit all contributions to vindeckyy/Solar-Flare.

Branch & pull request workflow#

Topic branch from master, one logical change per commit with conventional subjects (feat/fix/docs/test). Rebase when stale. Never commit build trees, credentials, local state, or unrelated submodule bumps. Preserve protocol identifiers, config paths, and service compatibility unless the change ships an explicit migration plan. Copy the 11-item PR checklist from CONTRIBUTING.md into the PR description: problem statement, GoogleTest coverage at 100% of changed code, full test_sunshine pass, Doxygen + BUILD_DOCS=ON green, user docs updated, clang-format clean, diff-check clean, npm run build green for frontend changes, en.json-only locale, no generated output, upstream links where relevant, fork-target PR.

bash

git submodule update --init --recursive
cmake -S . -B cmake-build-dev -G Ninja -DCMAKE_BUILD_TYPE=Debug -DBUILD_TESTS=ON -DBUILD_DOCS=OFF
cmake --build cmake-build-dev --target test_sunshine -j2
./cmake-build-dev/tests/test_sunshine --gtest_filter='ConfigTest.*' --gtest_brief=1
./cmake-build-dev/tests/test_sunshine --gtest_brief=1
clang-format --dry-run --Werror src/path/to/changed.cpp
git diff --check
npm run build

Web UI, CI & reporting#

The Web UI is a multi-entry Vite app, not a routed SPA: Navbar owns navigation, init.js bootstraps theme/locale per entry, sunshine.css holds the design system, Vue SFCs own interactive config, EJS files own static shells. Keep endpoints and form serialization independent of visuals, animate only state changes, and honor prefers-reduced-motion. Build via the CMake web-ui target (npm run dev for iteration, npm run build before submit) and refresh README screenshots when layout changes. CI runs the Web bundle job plus Linux compile + test_sunshine under Xvfb with coverage upload, using release_version 0.0.0-ci; release binaries never come from CI. Report bugs with repro steps and redacted logs, distro and desktop session, GPU/backend/encoder, Moonlight client version, and source/binary/CI build provenance.

PreviousSecurity Policy Next Maintainer Release Guide