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
Copy file name to clipboardExpand all lines: .yamato/code-coverage.yml
+33-7Lines changed: 33 additions & 7 deletions
Original file line number
Diff line number
Diff line change
@@ -1,10 +1,36 @@
1
1
{% metadata_file .yamato/project.metafile %} # All configuration that is used to create different configurations (used in for loops) is taken from this file.
2
2
---
3
-
4
-
# Runs package tests in order to determine code coverage of the NGO package.
5
-
# In essence, it's performing the same task as .yamato/package-test jobs with the overhead being the measured code coverage
6
-
# It's ok for code coverage to be performed only on one platform (default) since code coverage won't change much between those.
7
-
# Default platform was chosen (ubuntu) since it's the fastest and most resource friendly with default editor.
# It may seem that there is only 1 job defined, but we are using for loops based on .yamato/project.metafile configuration. Yamato "compiles" this code in order to generate jobs with multiple given configurations
14
+
# Jobs are generated using nested loops through:
15
+
# 1. For default platform only (Ubuntu) since coverage would not vary between platforms (no need for checks on more platforms)
16
+
# 2. For default editor version (trunk) since coverage would not vary between editors (no need for checks on more editors)
17
+
18
+
# 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.
19
+
# The downside of our current approach is that it can sometimes impact readability due to the use of nested if and for statements.
20
+
21
+
# The jobs name being generated would be for example "Code Coverage - NGO [testproject, 6000.0]" (name visible in Yamato) or "code_coverage_testproject_6000.0" (job name when querying for it)
# It may seem that there is only 1 job defined, but we are using for loops based on .yamato/project.metafile configuration. Yamato "compiles" this code in order to generate jobs with multiple given configurations
12
+
# Jobs are generated using nested loops (separate build phase and run phase). Worth noting that run phase uses the build as dependency:
13
+
# 1. For all console platform (Switch, ps4, ps5, xbox360, xboxOne) defined in test_platforms.console_ (in project.metafile)
14
+
# 2. For all supported Unity Editor versions (for NGOv2.X this means 6000.0+ editors defined in project.metafile)
15
+
# 3. For default project which serves as context
16
+
17
+
# 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.
18
+
# The downside of our current approach is that it can sometimes impact readability due to the use of nested if and for statements.
19
+
20
+
# The jobs name being generated would be for example "Build testproject - [win, 6000.0, il2cpp]" (name visible in Yamato) or "console_standalone_build_testproject_win_6000.0" (job name when querying for it)
0 commit comments