5.4 KiB
Build and tests
On Windows we use msys2 and ucrt64 to compile.
Prefix Windows build and test commands with C:\msys64\msys2_shell.cmd -defterm -here -no-start -ucrt64 -c.
Prefix build directories with cmake-build-.
The test executable is named test_sunshine and will be located inside the tests directory within
the build directory.
The project uses gtest as a test framework.
Sunshine tests must include tests/tests_common.h using the appropriate relative path, rather than including
<gtest/gtest.h> directly. The common header provides GoogleTest through the shared test support and makes
TEST use BaseTest, including its output capture and shared setup/teardown.
Group test headers first under // test includes, followed by // standard includes, // lib includes, and
// local includes, with a blank line between groups. Put shared test helpers in the test group, and omit empty
groups. Keep platform-specific headers and their group comments inside the appropriate preprocessor guards.
When a test depends on a particular include order, preserve that order and explain the dependency in a comment;
do not move the common header ahead of headers whose first-include behavior is being tested.
Add or update regression tests for new or modified source-code methods and behavior. Target 100% coverage on changed source code.
The regression-test requirement does not apply to build-system files, such as CMake scripts and dependency configuration. Validate build-system changes with appropriate configuration, build, and lint checks. Do not add dedicated build-system regression-test projects or fixtures for these changes.
Python tooling and formatting
From the repository root, run uv sync --locked to create or refresh .venv from pyproject.toml and uv.lock.
Re-run it after switching branches or changing either file or the third-party/lizardbyte-common submodule.
After changing dependency declarations or the submodule revision, run uv lock before syncing.
After native code changes, run uv run --locked lb-update-clang-format from the repository root. The command is
provided by third-party/lizardbyte-common; inspect the resulting diff for unrelated formatting changes.
Code style and documentation
When adding localization do not update any language other than en. This also means to exclude en-US or other variants.
Always add or update doxygen documentation.
The project requires that everything be documented in doxygen or the build will fail.
Primary doxygen comments should be done like so:
/**
* @brief Describe the function, structure, etc.
*
* @param my_param Describe the parameter.
* @return Describe the return.
*/
Inline doxygen comments should use ///< ... instead of /**< ... */.
Always follow the style guidelines defined in .clang-format for c/c++ code.
Do not add decorative separator comments, including dashed banners that label groups of tests. Use descriptive test names and code structure to show the grouping instead.
Issues and pull requests
When asked to create an issue or pull request, use the templates provided by the LizardByte/.github repo or LizardByte/Sunshine repo, with the Sunshine templates taking precedence if both exist. At the end of the issue or pull request body, add an attribution naming the AI agent, model, and thinking level used to generate it. Repeat that attribution in a separate comment on the created issue or pull request. For example:
> This issue was generated by ChatGPT 6 Sol, extra high thinking level
When asked to create an issue, do only enough investigation to verify and accurately describe the problem unless the user also asks for an investigation. Keep the issue concise: state the observed behavior, expected behavior, and reproduction steps or evidence when available. Do not include an exhaustive root-cause analysis or implementation plan in the issue. This limit applies only to creating issues; investigate or fix issues fully when asked.
Code Review Rules
Check new and modified tests for the common-header and include-group conventions above. Request
tests_common.h instead of direct GoogleTest includes, and ensure shared test helpers are in the test include
group. Verify any documented include-order dependency before asking the author to reorder headers.
Report concrete issues introduced by the change that the contributor can address. For each finding, explain the triggering condition, impact, and a practical fix; point to the relevant code or test. Keep workflow status separate from code findings.
If GitHub Actions workflows are queued for maintainer approval, or a dependent check times out before its job can run, do not leave an inline comment, request changes, or ask the contributor to run the workflows. The maintainer controls approval. If the missing results materially limit the review, mention that once in the review summary as a verification limit for the maintainer. Review actual failed checks for change-related problems when their logs are available.
For pull request reviews, verify the current PR head and mergeability against its target branch. If conflicts are confirmed, tell the author in the review summary that the PR needs to be rebased and the conflicts resolved before merging. Do not infer conflicts from an unknown or pending mergeability status.
When approving a pull request, the approval itself is sufficient. Do not add a comment solely to accompany it.