ci: Setting up conditional CI runs depending on PR comment trigger (#3580)

This PR aims to address the issue of "overdoing" the CI tests which due
to distribution times often lead to very long wait times.

First thing is that I failed to notice that `targets` and `drafts`
conditions are configured as separate items in a list (see PR job
trigger changes). In our CI, basic triggers in a list are combined with
an OR operator, meaning the job will run if any of the conditions are
met. This lead to test being executed on draft PRs.

What I'm changing is

1. Tests will correctly **not run** on draft PRs and if PR is not
targeting one of specified branches
2. PR trigger tests will execute only if there are changes in package or
project. For for example DOCS only changes no tests will run (in the
future we can improve that if for example we would have a test that
verifies typos etc)

This change should improve our workflow with CI as well as save some
resources for others

**NOTE THAT**
By default the PR trigger it's triggered if

1. PR targets develop or release branches
2. PR is not a draft
3. PR changes files in package or TestProjects folders (doesn't run on
for example DOCS only changes)

Note that in other cases you can trigger it by writing a comment `/ci
ngo` in the PR thread (if for example you want to test it on draft PR)

## Additional stuff
I also used that occasion to remove disable-burst file. We are not using
it and I included more advanced version in
#3557
so if we ever need it we can reuse that one. Because of that I will
remove it to avoid any confusion

## Steps after approval
I will remove the mandatory PR trigger job from branch settings since
now it will not always run (eg. only DOCS changes) and would block PRs
otherwise

## Backports

#3581

## Testing & QA
I verified that

1. PR trigger gets executed correctly when we have package or project
changes
4. I verified that the fact of tests running blocks PR from merging

## Documentation
I added explanation in jobs comments

## Jira ticket
MTT-12903

Author: michalChrobot

.yamato/_triggers.yml

@@ -2,42 +2,47 @@
 ---
 
 # DESCRIPTION--------------------------------------------------------------------------
-# This configuration defines three main CI trigger patterns:
-# 1. Pull Request Validation: Validation performed on PR basis
-# 2. Nightly Development: Test set run nightly (validates most important test cases)
-# 3. Weekly Full Validation: Test set run weekly (validates all test cases to prevent any surprises)
-# Each pattern represents different balance between validation depth, execution time and CI resource usage
+  # This configuration defines three main CI trigger patterns:
+    # 1. Pull Request Validation: Validation performed on PR basis
+    # 2. Nightly Development: Test set run nightly (validates most important test cases)
+    # 3. Weekly Full Validation: Test set run weekly (validates all test cases to prevent any surprises)
+  # Each pattern represents different balance between validation depth, execution time and CI resource usage
 
 # TRIGGER PATTERNS-------------------------------------------------------------------
+
 # Pull Request:
-# This test validates Standards, Package tests, Project tests and Desktop standalone tests to ensure that main platforms are covered
-# Triggers on PRs to develop, develop, and release branches
-# Focuses on critical validation paths that we should validate before merging PRs
-# Cancels previous runs on new commits
-# Excludes draft PRs
+  # This test validates Standards, Package tests, Project tests and Desktop standalone tests to ensure that main platforms are covered
+  # Focuses on critical validation paths that we should validate before merging PRs. It also cancels previous runs on new commits
+  # By default it's triggered if
+    # 1) PR targets develop, develop-2.0.0 or release branches
+    # 2) PR is not a draft
+    # 3) PR changes files in package or testproject folders (doesn't run on for example DOCS only changes)
+
+  # Note that in other cases you can trigger it by writing a comment "/ci ngo" in the PR thread
 
 # Nightly:
-# This test validates same subset as pull_request_trigger with addition of mobile/console tests and webgl builds
-# Runs daily on develop (local configuration)
-# Includes all test types but only on trunk.
-# Adds platform-specific and APV validation
+  # This test validates same subset as pull_request_trigger with addition of mobile/console tests and webgl builds
+  # Runs daily on develop (local configuration)
+  # Includes all test types but only on trunk.
+  # Adds platform-specific and APV validation
 
 # Weekly:
-# This test validates same subset as develop_nightly but runs per all supported editors as well as executes code coverage test and runs project standards per project
-# Runs across all supported editor versions
-# Includes code coverage analysis
-# Validates all projects and standards
+  # This test validates same subset as develop_nightly but runs per all supported editors as well as executes code coverage test and runs project standards per project
+  # Runs across all supported editor versions
+  # Includes code coverage analysis
+  # Validates all projects and standards
 
 # CONFIGURATION STRUCTURE--------------------------------------------------------------
-# Jobs configurations are generated by ensuring that all dependencies are successful.
-# The dependencies are taken from _run-all.yml file where we can gather multiple tests into proper sets
+  # Jobs configurations are generated by ensuring that all dependencies are successful.
+  # The dependencies are taken from _run-all.yml file where we can gather multiple tests into proper sets
 
 # QUALITY CONSIDERATIONS---------------------------------------------------------------
-# It's important to ensure that all dependencies exist (this can be verified in Yamato) since a modification in parameters may result in a given job not being generated, and thus we will not be able to run such erroneous job.
+  # It's important to ensure that all dependencies exist (this can be verified in Yamato) since a modification in parameters may result in a given job not being generated, and thus we will not be able to run such erroneous job.
 
 
 #-----------------------------------------------------------------------------------
 
+
 # Run all relevant tasks when a pull request targeting the develop or release branch is created or updated.
 # In order to have better coverage we run desktop standalone tests with different configurations which allows to mostly cover for different platforms, scripting backends and editor versions.
 # This job will FIRST run "run_quick_checks" jobs (defined in _run-all.yml) since it's the dependency of project pack jobs which is on the lowest dependency tier. This runs the fastest checks (like PVP or code standards) and ONLY IF those pass it will run the rest of the tests.
@@ -60,15 +65,18 @@ pull_request_trigger:
     - .yamato/desktop-standalone-tests.yml#desktop_standalone_test_testproject_win_il2cpp_6000.0
     - .yamato/cmb-service-standalone-tests.yml#cmb_service_standalone_test_testproject_ubuntu_il2cpp_trunk
   triggers:
+    # Note that PR tests will run ONLY if we are changing package/sample code. If changes are let's say docs only no tests will be triggered
+    # TODO: consider setting up and running tests from Examples/
+    # TODO: or docs only changes are spelling/link check
+    expression: |-
+      pull_request.comment eq "ngo" OR
+      ((pull_request.target eq "develop" OR
+      pull_request.target eq "develop-2.0.0" OR
+      pull_request.target match "release/*") AND
+      NOT pull_request.draft AND
+      (pull_request.changes.any match "com.unity.netcode.gameobjects/**" OR
+      pull_request.changes.any match "testproject/**"))
     cancel_old_ci: true
-    pull_requests:
-      - targets:
-          only:
-            - "develop"
-            - "develop-2.0.0"
-            - "/release\/.*/"
-      - drafts: false
-
 
 # Run all tests on trunk on nightly basis.
 # Same subset as pull_request_trigger with addition of mobile/desktop/console tests and webgl builds

.yamato/disable-burst-if-requested.py

@@ -24,7 +24,6 @@ Additional documentation and release notes are available at [Multiplayer Documen
 
 - Fixed issue where a client, under above average latency and packet loss conditions, could receive multiple NetworkTransform state updates in one frame and when processing the state updates only the last state update would be applied to the transform if interpolation was disabled. (#3614)
 
-
 ### Security