Merge branch 'develop-2.0.0' into automated-netcode-releases-2.x

Author: michalChrobot

.github/ISSUE_TEMPLATE/bug_report.md

@@ -2,7 +2,7 @@
 name: Bug report
 about: Create a report to help us improve
 title: ''
-labels: stat:awaiting triage, type:bug
+labels: stat:awaiting-triage, stat:reply-needed, type:bug
 assignees: ''
 
 ---
@@ -40,4 +40,4 @@ If applicable, add screenshots to help explain your problem.
 
 ### Additional Context
 
-Add any other context about the problem here. Logs, code snippets would be useful here but please also consider attaching a minimal Unity project that reproduces the issue.
+Add any other context about the problem here. Logs, code snippets would be useful here but please also consider attaching a minimal Unity project that reproduces the issue.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -2,7 +2,7 @@
 name: Feature Request
 about: Suggest an idea for this project
 title: ''
-labels: stat:awaiting triage, type:feature
+labels: stat:awaiting-triage, stat:reply-needed, type:feature
 assignees: ''
 
 ---

.github/ISSUE_TEMPLATE/rfc-tracking-issue.md

@@ -4,14 +4,14 @@ Replace this block with what this PR does and why. Describe what you'd like revi
 )
 
 ### Jira ticket
-_Link to related jira ticket ([Use the smart commits](https://support.atlassian.com/bitbucket-cloud/docs/use-smart-commits/))_
+_Link to related jira ticket ([Use the smart commits](https://support.atlassian.com/bitbucket-cloud/docs/use-smart-commits/)). Short version (e.g. MTT-123) also works and gets auto-linked_
 
 ### Changelog
 [//]: # (updated with all public facing changes  - API changes, UI/UX changes, behaviour changes, bug fixes. Remove if not relevant.)
 
 - Added: The package whose Changelog should be added to should be in the header. Delete the changelog section entirely if it's not needed.
 - Fixed: If you update multiple packages, create a new section with a new header for the other package.
-- Removed/Deprecated/Changed: Each bullet should be prefixed with Added, Fixed, Removed, Deprecated, or Changed to indicate where the entry should go
+- Removed/Deprecated/Changed: Each bullet should be prefixed with Added, Fixed, Removed, Deprecated, or Changed to indicate where the entry should go.
 
 <!--  Uncomment and mark items off with a * if this PR deprecates any API:
 ### Deprecated API
@@ -31,12 +31,14 @@ We should always evaluate if the changes in this PR require any documentation ch
 - Includes documentation for previously-undocumented public API entry points.
 - Includes edits to existing public API documentation.
 
-## Testing & QA
+## Testing & QA (How your changes can be verified during release Playtest)
 [//]: #  (
 This section is REQUIRED and should describe how the changes were tested and how should they be tested when Playtesting for the release.
 It can range from "edge case covered by unit tests" to "manual testing required and new sample was added".
 Expectation is that PR creator does some manual testing and provides a summary of it here.)
 
+<!-- Add any performance testing results here if relevant. -->
+
 ### Functional Testing
 [//]: # (If checked, List manual tests that have been performed.)
 _Manual testing :_
@@ -50,12 +52,13 @@ _Does the change require QA team to:_
 
 - [ ] `Review automated tests`?
 - [ ] `Execute manual tests`?
+- [ ] `Provide feedback about the PR`?
 
-If any boxes above are checked, please add QA as a PR reviewer.
+If any boxes above are checked the QA team will be automatically added as a PR reviewer.
 
-## Backport
+## Backports
 [//]: # (
 This section is REQUIRED and should link to the PR that targets other NGO version which is either develop or develop-2.0.0 branch
 Add the following to the PR title: "\[Backport\] ..."
 If this is not needed, for example feature specific to NGOv2.X, then just mention this fact.
-)
+)

.github/pull_request_template.md

@@ -16,8 +16,7 @@
     "com.unity.netcode.gameobjects/**/*",
     "Examples/**/*",
     "testproject/**/*",
-    "minimalproject/**/*",
-    "testproject-tools-integration/**/*"
+    "minimalproject/**/*"
   ],
   "packageRules": [
     // Run unity-upm-project and unity-upm-package only on weekends to reduce PR noise

.github/renovate.json5

@@ -17,7 +17,7 @@ jobs:
     steps:
       - name: semantic-pull-request
         # Internal Unity mirror available at jesseo/action-semantic-pull-request, but actions from private repos aren't supported, so continue to use the public one below
-        uses: amannn/action-semantic-pull-request@v5
+        uses: amannn/action-semantic-pull-request@v6
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         with:

.github/workflows/conventional-pr.yml

@@ -18,7 +18,7 @@ jobs:
       issues: write
 
     steps:
-      - uses: actions/stale@v9
+      - uses: actions/stale@v10
         with:
           # Only mark issues (not PRs) as stale
           any-of-labels: 'stat:awaiting-response'

.github/workflows/mark-stale-issue.yaml

@@ -1,12 +1,12 @@
-# This workflow is designed to verify that the pull request description contains a required sections that are important from quality perspective.
+# This workflow is designed to verify that the pull request description contains a required sections that are important from quality perspective.
 # ## Backport section is important as a reminder to account for backports for anyone that works with NGO repository (to 1.X or 2.X branches respectively).
 # ## Testing & QA section is important to ensure that the PR has appropriate testing coverage and is important when QA will evaluate PRs before Playtesting for the release.
 # ## Documentation section is important to ensure that the documentation is updated with the changes made in the PR.
 
 # If any of the sections is missing, the workflow will fail and block the PR from merging, prompting the developer to add those sections to the PR description.
 # The workflow is configured to run when PR is created as well as when it is edited which also counts simple description edits.
 
-name: "NGO - PR Verification"
+name: "NGO - PR description validation"
 
 on:
   pull_request:
@@ -17,14 +17,14 @@ on:
       - release/*
 
 jobs:
-  pr-verification:
+  pr-description-validation:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout code
-        uses: actions/checkout@v4
+        uses: actions/checkout@v5
 
       - name: Check PR description
-        uses: actions/github-script@v7
+        uses: actions/github-script@v8
         with:
           script: |
             const pr = context.payload.pull_request;
@@ -33,8 +33,8 @@ jobs:
             // List of mandatory PR sections
             const requiredSections = [
               {
-                header: '## Backport',
-                description: 'PR description must include a "## Backport" section. Please add this section and provide information about this PR backport to develop or develop-2.0.0 branch respectively or explain why backport is not needed.'
+                header: '## Backports',
+                description: 'PR description must include a "## Backports" section. Please add this section and provide information about this PR backport to develop or develop-2.0.0 branch respectively or explain why backport is not needed.'
               },
               {
                 header: '## Testing & QA',
@@ -43,6 +43,10 @@ jobs:
               {
                 header: '## Documentation',
                 description: 'PR description must include a "## Documentation" section. Please add this section and provide information about the documentation changes made in this PR. It is important to keep the documentation up to date with the code changes.'
+              },
+              {
+                header: '## Jira ticket',
+                description: 'PR description must include a "## Jira ticket" section. Please add this section and provide a link to the Jira ticket that corresponds to this PR. General rule should be that if the PR takes you more then a day of work it should have Jira ticket. Otherwise you can always write "N/A" in this section.'
               }
             ];
 
@@ -59,4 +63,4 @@ jobs:
               message += '\n\nPlease add them to your PR description.';
 
               core.setFailed(message);
-            }
+            }

.github/workflows/pr-verification.yml renamed to .github/workflows/pr-description-validation.yml

@@ -0,0 +1,36 @@
+# This workflow depend on the content of .github/pull_request_template.md file, which should contain the required sections that the script checks for
+# This also works in parallel with .github/workflows/pr-description-validation.yml which validates PR format
+# In contrast to .github/workflows/pr-description-validation.yml, this workflow is conditional and aims to ease the process of requesting QA review by automatically assigning the QA team  whenever a checkbox is marked
+
+# In case that the given checkboxes are marked the script will automatically add netcode-qa team as a reviewer.
+
+name: 'Assign QA Reviewer'
+
+on:
+  pull_request:
+    types: [opened, edited, synchronize, reopened]
+
+jobs:
+  assign-qa:
+    # This job only runs if the checkbox in the PR description exist and is checked.
+    if: >
+      contains(github.event.pull_request.body, '- [x] `Review automated tests`') ||
+      contains(github.event.pull_request.body, '- [x] `Execute manual tests`') ||
+      contains(github.event.pull_request.body, '- [x] `Provide feedback about the PR`')
+    runs-on: ubuntu-latest
+
+
+    steps:
+
+      - name: 'Assign QA Team'
+        uses: actions/github-script@v8
+        with:
+          github-token: ${{ secrets.GH_TOKEN }}
+          script: |
+            github.rest.pulls.requestReviewers({
+              owner: context.repo.owner,
+              repo: context.repo.repo,
+              pull_number: context.issue.number,
+              team_reviewers: ['netcode-qa']
+            });
+            console.log('Assigned netcode-qa for review.');

.github/workflows/qa-reviewer-assignment.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