Merge branch 'master' into river/cpu_plugin_behavior_tests

.github/workflows/mac.yml

@@ -192,15 +192,16 @@ jobs:
           cmake --build ${{ env.BUILD_DIR }} --parallel --config ${{ env.CMAKE_BUILD_TYPE }}
 
       - name: CMake configure, build and install - OpenVINO JS API
-        if: ${{ 'false' }} # 128446
-        # if: fromJSON(needs.smart_ci.outputs.affected_components).JS_API
-        run:
-          cmake -DCPACK_GENERATOR=NPM -DENABLE_SYSTEM_TBB=OFF -UTBB* -S ${{ env.OPENVINO_REPO }} -B ${{ env.BUILD_DIR }}
+        if: fromJSON(needs.smart_ci.outputs.affected_components).JS_API
+        run: |
+          cmake \
+            -DCPACK_GENERATOR=NPM \
+            -S ${{ env.OPENVINO_REPO }} \
+            -B ${{ env.BUILD_DIR }}
           
           cmake --build ${{ env.BUILD_DIR }} --parallel
           
           cmake -DCMAKE_INSTALL_PREFIX=${{ env.INSTALL_DIR_JS }} -P ${{ env.BUILD_DIR }}/cmake_install.cmake
-
       #
       # Upload build artifacts
       #
@@ -222,8 +223,7 @@ jobs:
           if-no-files-found: 'error'
 
       - name: Upload openvino js package
-        if: ${{ 'false' }} # 128446
-        # if: fromJSON(needs.smart_ci.outputs.affected_components).JS_API
+        if: fromJSON(needs.smart_ci.outputs.affected_components).JS_API
         uses: actions/upload-artifact@v3
         with:
           name: openvino_js_package
@@ -241,8 +241,7 @@ jobs:
   JS_API:
     name: OpenVINO JS API
     needs: [ Build, Smart_CI ]
-    if: ${{ 'false' }} # 128446
-    # if: fromJSON(needs.smart_ci.outputs.affected_components).JS_API
+    if: fromJSON(needs.smart_ci.outputs.affected_components).JS_API
     uses: ./.github/workflows/job_openvino_js.yml
     with:
       runner: 'macos-13'

.github/workflows/mac_arm64.yml

@@ -195,8 +195,6 @@ jobs:
         run: |
           cmake \
             -DCPACK_GENERATOR=NPM \
-            -DENABLE_SYSTEM_TBB=OFF -UTBB* \
-            -DENABLE_INTEL_GPU=OFF \
             -S ${{ env.OPENVINO_REPO }} \
             -B ${{ env.BUILD_DIR }}
           

cmake/features.cmake

@@ -155,12 +155,7 @@ endif()
 if(DEFINED ENV{TBBROOT} OR DEFINED ENV{TBB_DIR} OR DEFINED TBB_DIR OR DEFINED TBBROOT)
     set(ENABLE_SYSTEM_TBB_DEFAULT OFF)
 else()
-    if(LINUX AND AARCH64)
-        # CVS-126984: system TBB is not very stable on Linux ARM64 (at least on Ubuntu 20.04)
-        set(ENABLE_SYSTEM_TBB_DEFAULT OFF)
-    else()
-        set(ENABLE_SYSTEM_TBB_DEFAULT ${ENABLE_SYSTEM_LIBS_DEFAULT})
-    endif()
+    set(ENABLE_SYSTEM_TBB_DEFAULT ${ENABLE_SYSTEM_LIBS_DEFAULT})
 endif()
 
 ov_dependent_option (ENABLE_SYSTEM_TBB  "Enables use of system TBB" ${ENABLE_SYSTEM_TBB_DEFAULT}

docs/dev/ci/github_actions/overview.md

@@ -42,7 +42,10 @@ Additionally, several supporting workflows build and test OpenVINO for other ope
 
 ### Reusing GitHub Actions
 
-The listed workflows make use of the rich GitHub Actions official and community actions such as `actions/checkout`, `actions/upload-artifact` and others.
+The OpenVINO workflows make use of the rich official and community actions such as `actions/checkout`, `actions/upload-artifact` and others.
+
+Additionally, common jobs, i.e., those featured in several workflows, are extracted into _reusable workflows_. Read more about the used reusable workflows and how to write one [here](./reusable_workflows.md).
+
 You can find more information about reusing actions and workflows [here](https://github.com/marketplace?type=actions) and [here](https://docs.github.com/en/actions/using-workflows/reusing-workflows).
 
 ### Workflows' Triggers and Schedule
@@ -95,18 +98,18 @@ This workflow runs:
 
 ### Required Workflows
 
-The listed above workflows are not required at the moment, but it is strongly encouraged to pay attention to their [results](#finding-results-artefacts-and-logs) while working within the OpenVINO repository.
+The listed above workflows are **required**, i.e., a PR could not be merged if any of their stages fail. It is strongly encouraged to pay attention to their [results](#finding-results-artefacts-and-logs) while working within the OpenVINO repository.
 
 ### Structure of the Workflows
 
 This section provides the structural overview of the Linux, Windows and macOS workflows.
 
-The structure for all of them is the same:
+The structure for all of them is mostly the same:
 1. Clone OpenVINO repository and required resources
 2. Install build dependencies
 3. Build OpenVINO from source
 4. Pack and upload the artefacts (built OpenVINO and tests)
-5. Download and use the artefacts in the parallel jobs with different kinds of tests
+5. Download and use the artefacts in the parallel jobs with different tests
 6. Collect the test results and upload them as artefacts
 
 **NOTE**: some workflows may use the same structure or lack the last 3 steps and have tests present right after the `Build` step.
@@ -133,12 +136,12 @@ The `Build` job executes the first 4 steps:
 * builds from source with `cmake`
 * packs and uploads the artefacts using `actions/upload-artifact`
 
-The other jobs are responsible for running different kinds of tests using the built artefacts. They:
+The other jobs are responsible for running different tests using the built artefacts. They:
 * download and unpack the artefacts using `actions/download-artifact`
 * install the needed dependencies
 * run tests
 * collect test results
-* upload test results as [artefacts](#artefacts)
+* upload test results as [pipeline artefacts](#artefacts)
 
 #### Single Job Overview
 
@@ -218,17 +221,17 @@ To find logs for a pipeline:
 
 ## Custom Actions
 
-There are several actions written specifically for the needs of the OpenVINO workflows.
+Several actions are written specifically for the needs of the OpenVINO workflows.
 
-Read more about the available actions and what they do [here](./custom_actions.md).
+Read more about the available custom actions and what they do [here](./custom_actions.md).
 
 You can find more information about reusing actions and workflows [here](https://github.com/marketplace?type=actions) and [here](https://docs.github.com/en/actions/using-workflows/reusing-workflows).
 
 ## Machines
 
-The machines that execute the commands from the workflows are referred to as _runners_ in GitHub Actions.
+The machines that execute the commands from the workflows are called _runners_ in GitHub Actions.
 
-There are two types of runners available for the OpenVINO organization:
+Two types of runners are available for the OpenVINO organization:
 
 * [GitHub Actions Runners](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners) - runners provided and managed by GitHub
 * [Self-hosted Runners](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners) - runners created and managed by the OpenVINO CI team and linked to the OpenVINO repositories 

docs/dev/ci/github_actions/reusable_workflows.md

@@ -0,0 +1 @@
+# Overview of the Reusable Workflows used in the OpenVINO GitHub Actions CI

docs/dev/ci/github_actions/runners.md

@@ -2,22 +2,92 @@
 
 The machines that execute the commands from the workflows are referred to as _runners_ in GitHub Actions.
 
-There are two types of runners available in this repository:
-
+Two types of runners are available in this repository:
+   
 * [GitHub Actions Runners](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners) - runners provided and managed by GitHub
 * [Self-hosted Runners](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners) - runners created and managed by the OpenVINO CI team and linked to the OpenVINO repositories 
 
+The runners are specified for each job using the `runs-on` key. 
+
+An example `Build` job from the `linux.yml` workflow:
+```yaml
+Build:
+  ...
+  runs-on: aks-linux-16-cores-32gb
+  ...
+```
+
+The `aks-linux-16-cores-32gb` runners group is used for this job.
+
 ## Available GitHub Actions Runners
 
 GitHub provides runners with different combinations of available resources and software. 
 
 The OpenVINO repositories make use of the following runners:
 
-* [The default runners](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources): `ubuntu-22/20.04`, `windows-2019/2022`, `macos-12/13`
+* [The default runners](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources): `ubuntu-22/20.04`, `windows-2019/2022`, `macos-12/13`, etc.
   * Used for not-so-intensive memory and CPU tasks
-* [The larger runners](https://docs.github.com/en/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners#machine-sizes-for-larger-runners): you can find the list of available larger runners [here](https://github.com/openvinotoolkit/openvino/actions/runners)
+* [The larger runners](https://docs.github.com/en/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners#machine-sizes-for-larger-runners): you can find the list of the available larger runners [here](https://github.com/openvinotoolkit/openvino/actions/runners)
   * Used for memory and CPU heavy tasks
 
 ## Available Self-hosted Runners
 
+The self-hosted runners are dynamically spawned for each requested pipeline. 
+Several configurations of the self-hosted runners are available, they are identified by different group names.
+
+The group names generally follow the pattern: `aks-{OS}-{CORES_N}-cores-|{RAM_SIZE}gb|-|{ARCH}|`, where:
+* `{OS}` - the operating system: `win`/`linux`
+  * **Note**: Currently, only Windows and Linux self-hosted runners are available.
+* `{CORES_N}` - the number of cores available to the runners in the group: `4`/`8`/etc.
+* `|{RAM_SIZE}gb|` - **_optional_**, the RAM size in GB available to the runners in the group: `8`/`16`/etc.
+  * **Note**: The groups with unspecified `{RAM_SIZE}` consist of the runners with 32 GB of RAM
+* `|{ARCH}|` - **_optional_**, the architecture of the runners in the group: `arm`
+  * **Note**: The groups with unspecified `{ARCH}` consist of the `x86_64` runners
+
+Examples:
+* `aks-win-16-cores-32gb` - the Windows x86_64 runners with 16 cores and 32 GB of RAM available
+* `aks-linux-16-cores-arm` - the Linux ARM64 runners with 16 cores and 32 GB of RAM available
+
+The available configurations are:
+
+|             | Group Name        | CPU Cores    | RAM in GB        | Architecture         | Examples                                           |
+|-------------|-------------------|--------------|------------------|----------------------|----------------------------------------------------|
+| Windows     | `aks-win-*`       | `4`/`8`/`16` | `8`/`16`/`32`    | `x86_64`<sup>*</sup> | `aks-win-4-cores-8gb`/`aks-win-16-cores-32gb`      |
+| Linux       | `aks-linux-*`     | `4`/`8`/`16` | `16`/`32`        | `x86_64`<sup>*</sup> | `aks-linux-4-cores-16gb`/`aks-linux-16-cores-32gb` |
+| Linux ARM64 | `aks-linux-*-arm` | `16`         | `32`<sup>*</sup> | `arm`                | `aks-linux-16-cores-arm`                           |
+
+* `*` - Not specified in the group name
+
 ## How to choose a Runner
+
+The configuration of a runner required for a job (building, testing, etc.) stems from the nature of the job: the more memory and/or CPU-intensive it is, 
+the more robust configuration is required.
+
+The `Build` job in the `linux.yml` workflow uses the `aks-linux-16-cores-32gb` group as specified in the `runs-on` key:
+```yaml
+Build:
+  ...
+  runs-on: aks-linux-16-cores-32gb
+  ...
+```
+
+This group has machines with 16 core CPU and 32 GB of RAM, which could be utilized in parallel by the build tools used in the `Build` job. 
+
+The `C++ unit tests` job in the `linux.yml` workflow uses the `aks-linux-4-cores-16gb` group:
+```yaml
+CXX_Unit_Tests:
+  name: C++ unit tests
+  ...
+  with:
+    runner: aks-linux-4-cores-16gb
+    ...
+```
+
+As the C++ tests could not utilize the large number of cores for parallel execution as the build tools in the `Build` job could, 
+it would be pointless to use the `aks-linux-16-cores-32gb` group for them.
+
+The advice is to use runners with more cores/RAM size for the tasks that could load them.
+
+It is possible to experiment with different configurations before deciding, i.e.,
+run a job on runners from different groups and observe the gains; if they are significant, e.g., 60 minutes on a 4-core runner vs. 15 minutes on a 16-core runner, 
+it is better to use those with more cores.