-
Notifications
You must be signed in to change notification settings - Fork 10
Add new runner labels variable that includes runner specs #74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -6,24 +6,24 @@ These workflows integrate with **Bazel** and provide a consistent way to run **d | |
|
|
||
| ## Available Workflows | ||
|
|
||
| | Workflow | Description | | ||
| |-------------------------|--------------------------------------------------------------------| | ||
| | **Documentation Build** | Builds project documentation and deploys it to GitHub Pages | | ||
| | **Documentation Cleanup** | Cleans up old documentation versions from the `gh-pages` branch | | ||
| | **License Check** | Verifies OSS licenses and compliance | | ||
| | **Static Code Analysis**| Runs Clang-Tidy, Clippy, Pylint, and other linters | | ||
| | **Tests** | Executes tests using GoogleTest, Rust test, or pytest | | ||
| | **Rust Coverage** | Computes Rust code coverage and uploads HTML reports | | ||
| | **C++ Coverage** | Computes C++ code coverage using LCOV and uploads HTML reports | | ||
| | **Formatting Check** | Verifies code formatting using Bazel-based tools | | ||
| | **Copyright Check** | Ensures all source files have the required copyright headers | | ||
| | **Required Approvals** | Enforces stricter CODEOWNERS rules for multi-team approvals | | ||
| | **QNX Build (Gated)** | Builds QNX Bazel targets with environment-gated secrets for forks | | ||
| | **Documentation Verification** | Verifies documentation builds correctly and uploads results | | ||
| | **CodeQL Scan** | Performs security and quality analysis using GitHub CodeQL | | ||
| | **SCORE PR Checks** | Validates Bazel module naming conventions in pull requests | | ||
| | **Bzlmod Lockfile Check** | Enforces `MODULE.bazel.lock` consistency via `bazel mod tidy` | | ||
| | **Template Sync** | Synchronizes repository with eclipse-score/module_template | | ||
| | Workflow | Description | | ||
| | ------------------------------ | ----------------------------------------------------------------- | | ||
| | **Documentation Build** | Builds project documentation and deploys it to GitHub Pages | | ||
| | **Documentation Cleanup** | Cleans up old documentation versions from the `gh-pages` branch | | ||
| | **License Check** | Verifies OSS licenses and compliance | | ||
| | **Static Code Analysis** | Runs Clang-Tidy, Clippy, Pylint, and other linters | | ||
| | **Tests** | Executes tests using GoogleTest, Rust test, or pytest | | ||
| | **Rust Coverage** | Computes Rust code coverage and uploads HTML reports | | ||
| | **C++ Coverage** | Computes C++ code coverage using LCOV and uploads HTML reports | | ||
| | **Formatting Check** | Verifies code formatting using Bazel-based tools | | ||
| | **Copyright Check** | Ensures all source files have the required copyright headers | | ||
| | **Required Approvals** | Enforces stricter CODEOWNERS rules for multi-team approvals | | ||
| | **QNX Build (Gated)** | Builds QNX Bazel targets with environment-gated secrets for forks | | ||
| | **Documentation Verification** | Verifies documentation builds correctly and uploads results | | ||
| | **CodeQL Scan** | Performs security and quality analysis using GitHub CodeQL | | ||
| | **SCORE PR Checks** | Validates Bazel module naming conventions in pull requests | | ||
| | **Bzlmod Lockfile Check** | Enforces `MODULE.bazel.lock` consistency via `bazel mod tidy` | | ||
| | **Template Sync** | Synchronizes repository with eclipse-score/module_template | | ||
|
|
||
| --- | ||
|
|
||
|
|
@@ -574,16 +574,31 @@ This setup significantly reduces CI build time and improves reuse across differe | |
| All workflows in this repository use the following logic for selecting the runner: | ||
|
|
||
| ```yaml | ||
| runs-on: ${{ vars.REPO_RUNNER_LABELS && fromJSON(vars.REPO_RUNNER_LABELS) || 'ubuntu-latest' }} | ||
| runs-on: ${{ vars.runner_labels_ghub_standard_x64 && fromJSON(vars.runner_labels_ghub_standard_x64) || vars.REPO_RUNNER_LABELS && fromJSON(vars.REPO_RUNNER_LABELS) || 'ubuntu-latest' }} | ||
| ``` | ||
|
|
||
| This means: | ||
|
|
||
| - If your repository defines a variable named `REPO_RUNNER_LABELS` (e.g., in repository or organization settings), its value will be used as the runner label(s). | ||
| - If your repository defines a variable named `runner_labels_ghub_standard_x64` or `REPO_RUNNER_LABELS` (e.g., in repository or organization settings), its value will be used as the runner label(s). | ||
| This allows you to use **self-hosted runners** or any custom runner configuration. | ||
| - If `REPO_RUNNER_LABELS` is **not set**, the workflow will default to GitHub-hosted `ubuntu-latest`. | ||
| - If `runner_labels_ghub_standard_x64` or `REPO_RUNNER_LABELS` is **not set**, the workflow will default to GitHub-hosted `ubuntu-latest`. | ||
|
|
||
| **Why?** | ||
| This approach allows forked repositories or projects with special requirements to use their own runners, while everyone else gets a reliable default. | ||
|
|
||
| > ℹ️ **Tip:** To use a self-hosted runner, set the `REPO_RUNNER_LABELS` variable in your repository or organization settings to the label(s) of your runner. | ||
| > ℹ️ **Tip:** To use a self-hosted runner, set the `runner_labels_ghub_standard_x64` or `REPO_RUNNER_LABELS` variable in your repository or organization settings to the label(s) of your runner. | ||
|
|
||
| ### Runner labels variable naming convention | ||
|
|
||
| Since it is very likely the case that different workflows will need different runners of different sizes, oses and architectures to be cost efficiently using the runner infrastructure the variable that specifies the runner labels shall follow this naming convention: | ||
MTomBosch marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| `runner_labels_<os>_<size>_<architecture>` | ||
|
|
||
| As of today following runner label variables are supported: | ||
|
|
||
| - runner_labels_ghub_standard_x64 | ||
| - os: ghub - GitHub Ubuntu latest OS image | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we should distinguish between ubuntu 22, 24 and 26
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is just reflecting the fact that within score we also only used "ubuntu-latest" runners if I am not mistaken. If we decide we want to stick to one specific version then I would change accordingly the variable name as well.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yeah, most workflow use latest = 24. Which is something I'll adjust when I finally start working on workflows... Was hoping to start for weeks. Nevertheless some jobs must stay on ubuntu 22 for now, as they simply dont work on 24. |
||
| - size: standard - Maps to the specs of the "Ubuntu latest" GitHub hosted runner | ||
| - architecture: x64 - Maps to the architecture of the standard "Ubuntu latest" GitHub hosted runner. The value is taken from the [GitHub hosted runners reference page](https://docs.github.com/en/actions/reference/runners/github-hosted-runners) | ||
|
|
||
| Due to this new naming convention the variable **REPO_RUNNER_LABELS is deprecated** and will be removed eventually! | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isnt REPO_RUNNER_LABELS for that ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. It is for the same thing but more specific/transparent to the reader of the workflow file what runner is intended to be used without being forced to check the runtime logs of a workflow.
And it allows to use differently sized runners within workflows of the same repository. I kept the REPO_RUNNER_LABELS to stay backwards compatible with the current implementation.
For SCore this flexibility might not be required yet but for companies that build a SCORE based middleware distribution and are reusing the workflow/action yaml files in their private GitHub org such flexibilty of the runner selection is already required right now. I would like to use the same GH org wide set variables for all repositories and not use REPO_RUNNER_LABELS for the Score repo forks(resp. manually synced repos) and another set of variables for the purely internal repos.
But in the end I agree it is (at the moment) a cosmetic change and not really required yet. But it does not hurt also to improve sth. before we urgently need it ;)