You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# GitHub Actions workflow to monitor Yamato CI job state on pull requests
2
+
# We are using https://cli.github.com/manual/gh_pr_checks
3
+
# The aim is to ensure that conditionally triggered Yamato jobs are completed successfully before allowing merges
4
+
5
+
# This job will be required in branch protection rules for develop, develop-2.0.0, and release/* branches. It's only goal will be to ensure that Yamato jobs are completed successfully before allowing Pr to merge.
6
+
# Note that conditional jobs will have 30s to show which is always the cas since they are showing up as soon as in distribution stage.
# This test validates Standards, Package tests, Project tests and Desktop standalone tests to ensure that main platforms are covered
15
-
# Focuses on critical validation paths that we should validate before merging PRs. It also cancels previous runs on new commits
16
-
# By default it's triggered if
16
+
# We have two PR triggers:
17
+
# 1) Minimal PR checks that run on all PRs (even if only docs are changed)
18
+
# 2) More extensive pr_code_changes_checks that run if code is changed. This test validates Standards, Package tests, Project tests and Desktop standalone tests to ensure that main platforms are covered
19
+
# By default pr_minimal_required_checks it's triggered if
17
20
# 1) PR targets develop, develop-2.0.0 or release branches
18
21
# 2) PR is not a draft
19
-
# 3) PR changes files in package or testproject folders (doesn't run on for example DOCS only changes)
22
+
# Then pr_code_changes_checks it's triggered if the same conditions apply plus:
23
+
# 1) PR changes code in com.unity.netcode.gameobjects package (Editor, Runtime or Tests folders) or in testproject folder or package.json file
20
24
21
25
# Note that in other cases you can trigger it by writing a comment "/ci ngo" in the PR thread
22
26
@@ -40,16 +44,32 @@
40
44
# 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.
# After some experimenting with CI setups we discovered that even though sometimes we don't need CI to run (no reason to run package tests if only Documentation is changed) there are some checks that devs may not realize but changes in seemingly unrelated files will cause their failures
50
+
# This trigger was created to ensure that ALL PRs run this minimal check even when we don't need to run full tests
# Run all relevant tasks when a pull request targeting the develop or release branch is created or updated.
47
67
# 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.
48
68
# 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.
49
69
# This optimization allows to speed up feedback look for any "obvious" errors and save resources.
50
70
# Since standards job is a part of initial checks it's not present as direct dependency here!!!!!!!!!!!!!!!!!!!!
- python Tools/scripts/release.py # Needed to ensure that CHANGELOG is properly formatted for this test due to the fact that we have bumped package version (to properly perform vetting tests)
{% metadata_file .yamato/project.metafile %} # All configuration that is used to create different configurations (used in for loops) is taken from this file.
# This configuration defines vetting tests for the Tools package which allows to validate if the package is in releasable state. This is important in particular because of API validation that allows to detect if we are introducing any new APIs that will force us to bump package version to new minor
4
+
# This configuration defines vetting tests for the NGO package which allows to validate if the package is in releasable state. This is important in particular because of API validation that allows to detect if we are introducing any new APIs that will force us to bump package version to new minor
5
5
# If this test fails with new API error we should either make those API internal OR bump package version to new minor (note that the package version reflects the current package state)
6
6
7
7
# Note that we are packing the package only (no project context) so if package have any soft dependencies then project should be used to test it (to enable those APIs)
8
8
{% for editor in validation_editors.minimal -%}
9
9
vetting_test:
10
-
name: MP Tools - Vetting Test (Win, {{editor}} LTS)
0 commit comments