Added ci README file

Author: michalChrobot

.yamato/CI_README.md

@@ -0,0 +1,80 @@
+# Netcode for GameObjects CI Documentation
+
+## Overview
+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.
+
+## Test Configurations
+CI related files are present inside .yamato/ folder and we can distinguish specific tests
+
+### Helper jobs
+- `.yamato/package-pack.yml` responsible for generating package artifacts (.tgz) required for testing and publishing.
+- `.yamato/project-pack.yml` responsible for generating package artifacts (.tgz) required for testing and publishing. This packs all packages of a given project.
+- `.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.
+
+### In-Editor Tests
+- `.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.
+
+### Standalone Tests
+- `.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.
+
+### Wrench jobs
+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.
+
+## Jobs Configuration Structure
+This section explains some configuration details that may be confusing while looking at .yml files.
+
+### Job Generation
+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.
+
+### Job Naming Convention
+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`
+
+## Platform Support
+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 (2021.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)
+
+## Design Considerations
+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.