This document provides an overview of the Continuous Integration (CI) implementation for Netcode for GameObjects. Specifics of each test are described within related files (for example .yamato/package-tests.yml) and this file present high level overview related to overall implementation.

CI related files are present inside .yamato/ folder and we can distinguish specific tests

• .yamato/package-pack.yml responsible for generating package artifacts (.tgz) required for testing and publishing.
• .yamato/_run-all.yml responsible for grouping tests into groups for easier management (for example "all console tests").
• .yamato/_triggers.yml responsible for defining triggers (PR, nightly, weekly etc.) and defining which tests to run.
• disable-burst-if-requested.py responsible for helping to disable burst if needed.
• .yamato/project.metafile being the central configuration file defining test environments, platforms, projects, editors and other parameters used.

• .yamato/package-tests.yml responsible for running package tests.
• .yamato/project-tests.yml responsible for running project tests.
• .yamato/project-updated-dependencies-test.yml responsible for running tests after updating dependencies to latest ones.
• .yamato/project-standards.yml responsible for running standards check on a package.
• .yamato/code-coverage.yml responsible for running code coverage analysis.
• .yamato/performance-tests.yml responsible for running performance tests.
• .yamato/webgl-build.yml responsible for making a build for webgl platform.

• .yamato/desktop-standalone-tests.yml responsible for running tests on standalone desktops.
• .yamato/console-standalone-test.yml responsible for running tests on standalone consoles.
• .yamato/mobile-standalone-test.yml responsible for running tests on standalone mobiles.

This file is auto generated by wrench and used for automating release process. Those tests can also be used by our CI as dependencies.

• .yamato/wrench/api-validation-jobs.yml responsible for validating api for a given package version (for example if there are no breaking changes when updating patch version)
• .yamato/wrench/package-pack-jobs.yml responsible for generating package artifacts (.tgz) required for testing and publishing.
• .yamato/wrench/preview-a-p-v.yml responsible for validating PVP (Package Verification Profiles) standards for the package.
• .yamato/wrench/promotion-jobs.yml responsible for publishing.
• .yamato/wrench/publish-trigger.yml responsible for defining jobs that need to pass in order to publish.
• .yamato/wrench/recipe-regeneration.yml responsible for verifying regeneration of wrench recipes (no manual changes).
• .yamato/wrench/validation-jobs.yml responsible for running package tests.
• .yamato/wrench/wrench_config.json this is the configuration file for wrench.
• .yamato/generated-scripts/ is a collection of infrastructure instability detection tools.

This section explains some configuration details that may be confusing while looking at .yml files.

Our configuration uses a dynamic job generation approach based on the .yamato/project.metafile configuration. While it may appear that only one job is defined per file, the system (Yamato) actually generates multiple jobs through nested loops. Usually only 1 job is defined and then generated with multiple configurations/parameters but in case of standalone tests 2 jobs are defined which are responsible for building and then testing.

Because the jobs are being generated their names will be filled by given parameters from project.metfaile. For example jobs from .yamato/console-standalone-test may have names like:

• Display Name (in Yamato): Build testproject - [win, 6000.0, il2cpp]
• Internal Job Name (used when adding dependency for example): console_standalone_build_testproject_win_6000.0

Currently, the CI implementation supports the following platforms:

1. Console Platforms:
   • Switch
   • PS4
   • PS5
   • Xbox360
   • XboxOne
2. Mobile Platforms:
   • Android
   • iOS
3. Desktop Platforms:
   • Windows
   • Ubuntu
   • macOS
4. Unity Editor Versions
   • Supports NGOv1.X (2022.3+ editors)
5. Architectures
   • x64
   • ARM64 (This is present for consoles/mobiles but will be extended. More information is present in specific standalone test files)

In theory, we could manually write jobs for every configuration. However, this approach would be more error-prone, especially when modifications or fixes are needed, as it would require keeping track of all configurations. The downside of our current approach is that it can sometimes impact readability due to the use of nested if and for statements.