natas_hw
/
openvino
0
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

[GHA][DOCS] Update recommendations regarding the GHA runners and execution time (#23380)

This commit is contained in:
Denis Orlov 2024-03-13 19:07:45 +00:00 committed by GitHub
parent e8b30887cd
commit 03fd5911ad
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
4 changed files with 10 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
docs/dev/ci/github_actions/adding_tests.md
View File

@ -135,6 +135,11 @@ The [`fedora.yml`](./../../../../.github/workflows/fedora.yml) workflow example
## Test Time and Usage
Be mindful about time and runners usage when adding new steps, jobs and workflows. When adding any new test or changing
the scope of an existing test, always check the test execution time in your pull request. As a rule of thumb, the execution time
of any workflow in the precommit should be less than 60 minutes. Also note that even if, as recommended, the execution time is
less than 60 minutes, it may be unreasonably costly to run a powerful multi-core runner for a long time without a proper workload.
### Adding a Step
When adding a step in a job, check its execution time compared to other jobs. Try to

2
docs/dev/ci/github_actions/overview.md
View File

@ -62,7 +62,7 @@ included in the [Linux workflow](../../../../.github/workflows/linux.yml). They
* This trigger runs the workflow on a specified interval (e.g., nightly).
* In the example below: `'0 0 * * 3,6'` - learn more on [cron syntax](https://crontab.guru/)
* `on: pull_request` - pre-commit trigger
* This trigger runs the workflow when a PR is created targeting the `master` or `release`
* This trigger runs the workflow when a pull request (PR) is created targeting the `master` or `release`
branch and every time the PR is updated with new commits.
* In the example below, it additionally requires that the changed files conform to the path
globs specified under the `paths` key.

3
docs/dev/ci/github_actions/runners.md
View File

@ -7,6 +7,9 @@ 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
Generally, it is advised to use the GitHub Actions runners for light jobs, like labelers, code style checks, etc, whereas
longer workflows (such as builds or functional tests) should use the self-hosted runners.
The runners are specified for each job using the `runs-on` key.
An example `Build` job from the [`linux.yml`](./../../../../.github/workflows/linux.yml)

2
docs/dev/ci/github_actions/smart_ci.md
View File

@ -1,7 +1,7 @@
# Smart CI Overview
Smart CI is a feature designed to optimize pre-commit CI workflow by running only the necessary
builds and tests required to validate changes in a given Pull Request (PR).
builds and tests required to validate changes in a given pull request (PR).
For example, if a PR changes only the CPU plugin, GPU plugin tests are skipped in the pre-commit stage
for this PR, as they are unrelated. This approach reduces execution time for isolated changes