Adjusted comments after creation of CI_README file

Author: michalChrobot

.yamato/_run-all.yml

@@ -5,13 +5,8 @@
   # Those jobs group together related test as dependencies to allow to easily manage running a given set of tests.
   # This enables efficient test execution for different validation scenarios
 
-# CONFIGURATION STRUCTURE--------------------------------------------------------------
-  # 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
-  # Jobs are generated using nested loops through:
-  
-  # It's important to ensure that all generated in such way dependencies exist (this can be verified in Yamato)
-  # 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.
+# 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.
 
 #-----------------------------------------------------------------------------------
 

.yamato/_triggers.yml

@@ -32,6 +32,10 @@
   # 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.
+
+
 
 #-----------------------------------------------------------------------------------
 

.yamato/code-coverage.yml

@@ -10,16 +10,10 @@
     # Additional metrics for coverage analysis
 
 # CONFIGURATION STRUCTURE--------------------------------------------------------------
-  # 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
   # Jobs are generated using nested loops through:
     # 1. For default platform only (Ubuntu) since coverage would not vary between platforms (no need for checks on more platforms)
     # 2. For default editor version (trunk) since coverage would not vary between editors (no need for checks on more editors)
-  
-  # 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.
-  
-  # 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)
-  
+
 #TECHNICAL CONSIDERATIONS---------------------------------------------------------------
   # In theory this job also runs package tests, but we don't want to use it as default since is heavier (because of added coverage analysis) and coverage is not changing that often
   # Requires Unity Editor installation

.yamato/console-standalone-test.yml

@@ -6,17 +6,11 @@
   # Those tests cover both PlayMode and EditMode tests from package test assemblies.
 
 # CONFIGURATION STRUCTURE--------------------------------------------------------------
-  # 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
   # Jobs are generated using nested loops (separate build phase and run phase). Worth noting that run phase uses the build as dependency:
     # 1. For all console platform (Switch, ps4, ps5, xbox360, xboxOne)
     # 2. For all supported Unity Editor versions (for NGOv2.X this means 6000.0+ editors)
   ` # 3. For the default project.
-  
-  # 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.
-  
-  # 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)   
-  
+
 # TECHNICAL CONSIDERATIONS---------------------------------------------------------------
   # For console devices a split is required into two phases:
     # 1. Build Phase: Creates standalone players for console platforms

.yamato/desktop-standalone-tests.yml

@@ -6,18 +6,12 @@
   # Those tests cover both PlayMode and EditMode tests from package test assemblies.
 
 # CONFIGURATION STRUCTURE--------------------------------------------------------------
-  # 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
   # Jobs are generated using nested loops (separate build phase and run phase). Worth noting that run phase uses the build as dependency:
     # 1. For all desktop platform (Windows, macOS, Ubuntu)
     # 2. For all supported Unity Editor versions (for NGOv2.X this means 6000.0+ editors)
     # 3. For the default project.
     # 4. For all scripting backends (mono, il2cpp)
-  
-  # 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.
-  
-  # The jobs name being generated would be for example "Standalone Build - NGO testproject - [win, mono, 6000.0]" (name visible in Yamato) or "desktop_standalone_build_testproject_win_mono_6000.0" (job name when querying for it)   
-  
+
 # TECHNICAL CONSIDERATIONS---------------------------------------------------------------
   # For desktop devices a split is into two phases is not required but we use it for consistency with setup of others standalone platforms:
     # 1. Build Phase: Creates standalone players for desktop platforms

.yamato/mobile-standalone-test.yml

@@ -6,17 +6,11 @@
   # Those tests cover both PlayMode and EditMode tests from package test assemblies.
 
 # CONFIGURATION STRUCTURE--------------------------------------------------------------
-  # 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
   # Jobs are generated using nested loops through:
     # 1. For all mobile platform (Android, iOS)
     # 2. For all supported Unity Editor versions (for NGOv2.X this means 6000.0+ editors)
     # 3. For the default project.
 
-  # 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.
-  
-  # The jobs name being generated would be for example "Build testproject - [win, 6000.0, il2cpp]" (name visible in Yamato) or "build_testproject_win_6000.0" (job name when querying for it)   
-  
 # TECHNICAL CONSIDERATIONS---------------------------------------------------------------
   # For mobile devices a split is required into two phases:
     # 1. Build Phase: Creates standalone players for mobile platforms

.yamato/package-pack.yml

@@ -8,15 +8,9 @@
   # Because of that validation we can detect errors at the early stage of testing so not to waste CI resources
 
 # CONFIGURATION STRUCTURE--------------------------------------------------------------
-  # 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
   # Jobs are generated using nested loops through:
     # 1. For all desktop platforms (Windows, Ubuntu, macOS)
 
-  # 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.
-
-  # The jobs name being generated would be for example "Package Pack (and x-ray) - NGO [win]" (name visible in Yamato) or "package_pack_-_ngo_win" (job name when querying for it)   
-
 # TECHNICAL CONSIDERATIONS---------------------------------------------------------------
   # Job does not require Unity Editor in order to perform packing.
   # Job uses PVP x-ray for lightweight validation

.yamato/package-tests.yml

@@ -7,16 +7,10 @@
   # Additionally it combines Package Verification Pipeline (PVP) validation. This ensures that package is compatible with Unity standards
 
 # CONFIGURATION STRUCTURE--------------------------------------------------------------
-  # 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
   # Jobs are generated using nested loops through:
     # 1. For all desktop platforms (Windows, Ubuntu, macOS)
     # 2. For all supported Unity Editor versions (for NGOv2.X this means 6000.0+ editors)
 
-  # 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.
-  
-  # The jobs name being generated would be for example "Package Test - NGO testproject [win, 6000.0]" (name visible in Yamato) or "package_test_-_ngo_6000.0_win" (job name when querying for it)   
-  
 # TECHNICAL CONSIDERATIONS---------------------------------------------------------------
   # This job runs in Editor context only (no player builds required)
   # No scripting backend variations needed (Editor context)

.yamato/performance-tests.yml

@@ -7,17 +7,11 @@
   # Currently because of lack of performance tests this job will always return "no tests have been selected" and because oif that it's not included in any trigger jobs.
 
 # CONFIGURATION STRUCTURE--------------------------------------------------------------
-  # 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
   # Jobs configurations are generated using nested loops through:
     # 1. For all desktop platforms (Windows, Ubuntu, macOS)
     # 2. For all supported Unity Editor versions (For NGOv2.X it means 6000+)
     # 3. For the default project (project is used only as a context for the build). TODO-comment: if performance tests would be included in projects then we should make an approperiate split.
 
-  # 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.
-  
-  # The jobs name being generated would be for example "Performance editor Tests - NGO testproject [win, 6000.0] (No Data Reporting)" (name visible in Yamato) or "performance_editor_tests_-_NGO_testproject_6000.0_no_data_reporting" (job name when querying for it)  
-  
 # TECHNICAL CONSIDERATIONS---------------------------------------------------------------
   # Tests are run in Editor context only
   # No performance metrics are reported to monitoring systems

.yamato/project-pack.yml

@@ -6,16 +6,10 @@
   # The job itself doesn't test anything specific but rather it prepares project packages that will be consumed by other pipeline jobs.
 
 # CONFIGURATION STRUCTURE--------------------------------------------------------------
-  # 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
   # Jobs configurations are generated using nested loops through:
     # 1. For all projects (testproject, minimalproject, testproject-tools-integration).
     # 2. For all desktop platforms (Win, Ubuntu, Mac)
 
-  # 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.
-  
-  # The jobs name being generated would be for example "Project Pack - testproject [win]" (name visible in Yamato) or "project_pack_-_testproject_win" (job name when querying for it)
-  
 # TECHNICAL CONSIDERATIONS--------------------------------------------------------------------
   # Job does not require Unity Editor in order to perform packing.
   # In theory, we could just use one platform for packing projects (for example ubuntu) but in order to reduce confusion we are using same platform as the job utilizing project pack as dependency.