Add new runner labels variable that includes runner specs

[MTomBosch]

Introduce runner labels variable that contains certain specs of the runner.

Goal is that on the long run we have multiple runner types and the workflow shall decide which runner suits best its workload.

Also this allows that within the same repo different workflow can use different types of runners. This might not be relevant for the OSS workflows but for enterprise GH orgs different self hosted runner types do make a lot of sense.

[Copilot]

Pull request overview

This PR introduces a new repository variable-based runner label selection mechanism intended to support multiple runner “profiles” (OS/size/architecture) across workflows, while keeping a fallback to existing runner selection behavior.

Changes:

• Updates runs-on across workflows to prefer a new runner labels variable before falling back to REPO_RUNNER_LABELS and then ubuntu-latest.
• Updates documentation for runner selection logic and adds a naming convention section for runner label variables.
• Cleans up the “Available Workflows” table formatting in the README.

Reviewed changes

Copilot reviewed 18 out of 18 changed files in this pull request and generated 20 comments.

Show a summary per file

File	Description
README.md	Documents new runner labels variable preference order and naming convention; adjusts workflows table formatting.
.github/workflows/tests.yml	Switches runs-on to new runner labels variable fallback chain.
.github/workflows/template-sync.yml	Switches runs-on to new runner labels variable fallback chain.
.github/workflows/static-analysis.yml	Switches runs-on to new runner labels variable fallback chain.
.github/workflows/score-pr-checks.yml	Switches runs-on to new runner labels variable fallback chain.
.github/workflows/rust-coverage.yml	Switches runs-on to new runner labels variable fallback chain.
.github/workflows/required-approvals.yml	Switches runs-on to new runner labels variable fallback chain.
.github/workflows/qnx-build.yml	Switches runs-on to new runner labels variable fallback chain.
.github/workflows/local_on_pr.yml	Switches runs-on to new runner labels variable fallback chain.
.github/workflows/license-check.yml	Switches runs-on to new runner labels variable fallback chain.
.github/workflows/format.yml	Switches runs-on to new runner labels variable fallback chain.
.github/workflows/docs.yml	Switches runs-on (docs build + deploy) to new runner labels variable fallback chain.
.github/workflows/docs-verify.yml	Switches runs-on to new runner labels variable fallback chain.
.github/workflows/docs-cleanup.yml	Switches runs-on to new runner labels variable fallback chain.
.github/workflows/cpp-coverage.yml	Switches runs-on to new runner labels variable fallback chain (preserving input fallback).
.github/workflows/copyright.yml	Switches runs-on to new runner labels variable fallback chain.
.github/workflows/codeql.yml	Switches runs-on to new runner labels variable fallback chain.
.github/workflows/bzlmod-lock-check.yml	Switches runs-on to new runner labels variable fallback chain.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[dcalavrezo-qorix]

why adding a new variable, can't you use the existing one?

Each company will add its own?

@MTomBosch what's the technical reason behind this?

[MTomBosch]

why adding a new variable, can't you use the existing one?

Each company will add its own?

@MTomBosch what's the technical reason behind this?

@dcalavrezo-qorix This repository is used to hold all the reusable workflows and composite actions in the context of score. This repository will get bigger and bigger over time contributing functionality to many different workflows. And although you could use one type of runner for all workflows from within one repository this would mean you need to use the biggest runner that can properly process all types of workload (workflows). And in score where the "ubuntu latest" runners do not cost any money I see that this is not really required.

But we (ETAS) have also a private organisation where we are reusing the cicd workflows and every runner minute is charged so we want to be cost efficiently using the runners. Also if some workflows can utilize big fat runners to be finished faster, then dedicated variables that tell that a "large" runner is requested/required would be required.

And the best ones to judge what kind of runner is required are the workflow developers. Because of that I defined the variable name based on some performance and os criteria.

So all in all for the current score workflows you are right that it does not bring much benefit and is technically not required but in our private GH org we already have use cases where this one totally generic variable is not sufficient to support the already known use cases.

Does that make sense to you?

[dcalavrezo-qorix]

why adding a new variable, can't you use the existing one?
Each company will add its own?
@MTomBosch what's the technical reason behind this?

@dcalavrezo-qorix This repository is used to hold all the reusable workflows and composite actions in the context of score. This repository will get bigger and bigger over time contributing functionality to many different workflows. And although you could use one type of runner for all workflows from within one repository this would mean you need to use the biggest runner that can properly process all types of workload (workflows). And in score where the "ubuntu latest" runners do not cost any money I see that this is not really required.

But we (ETAS) have also a private organisation where we are reusing the cicd workflows and every runner minute is charged so we want to be cost efficiently using the runners. Also if some workflows can utilize big fat runners to be finished faster, then dedicated variables that tell that a "large" runner is requested/required would be required.

And the best ones to judge what kind of runner is required are the workflow developers. Because of that I defined the variable name based on some performance and os criteria.

So all in all for the current score workflows you are right that it does not bring much benefit and is technically not required but in our private GH org we already have use cases where this one totally generic variable is not sufficient to support the already known use cases.

Does that make sense to you?

That's why I introduced vars.REPO_RUNNER_LABELS in the first place.

My question was more on the technical reason for introducing a second variable ( when the first one could hold multiple values being a JSON). What's the point?

[MTomBosch]

why adding a new variable, can't you use the existing one?
Each company will add its own?
@MTomBosch what's the technical reason behind this?

@dcalavrezo-qorix This repository is used to hold all the reusable workflows and composite actions in the context of score. This repository will get bigger and bigger over time contributing functionality to many different workflows. And although you could use one type of runner for all workflows from within one repository this would mean you need to use the biggest runner that can properly process all types of workload (workflows). And in score where the "ubuntu latest" runners do not cost any money I see that this is not really required.
But we (ETAS) have also a private organisation where we are reusing the cicd workflows and every runner minute is charged so we want to be cost efficiently using the runners. Also if some workflows can utilize big fat runners to be finished faster, then dedicated variables that tell that a "large" runner is requested/required would be required.
And the best ones to judge what kind of runner is required are the workflow developers. Because of that I defined the variable name based on some performance and os criteria.
So all in all for the current score workflows you are right that it does not bring much benefit and is technically not required but in our private GH org we already have use cases where this one totally generic variable is not sufficient to support the already known use cases.
Does that make sense to you?

That's why I introduced vars.REPO_RUNNER_LABELS in the first place.

My question was more on the technical reason for introducing a second variable ( when the first one could hold multiple values being a JSON). What's the point?

My points are:

1. When I am looking at multiple workflows in a repo and I am looking at the "runs-on" I (as workflow developer) would like to know briefly on what kind of runner the workflow is supposed to run. This information I do not see when looking at REPO_RUNNER_LABELS.
2. As a workflow developer (at least in our enterprise org) I do not want to know the actual and concrete labels of the runners as the runners are provided by a different team. This shall be hidden by the variable. Still I want to briefly know what runner is being used in the workflow
3. If I want to use different runners in workflows of a single repo or even in jobs of the same workflow I have no way to do it using just one generic variable. And we already foresee this usecase for score where e.g. some testing shall be done on arm runners but the build on x64 runners. Running an arm emulation (using qemu) on a x64 runner is horribly slow and should be avoided at any cost.

My conclusion is: Using the one variable is not flexible enough for the future workflows. And changing the variable now is not as costly as changing it in one year.

I have no problem at if you want to keep the REPO_RUNNER_LABELS for your own use case (then I would remove the deprecation hint in the Readme). But adding the support for the new variable would be highly appreciated from my company side.

@AlexanderLanin Please share your thoughts too.

[AlexanderLanin]

we should distinguish between ubuntu 22, 24 and 26

[MTomBosch]

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.

[AlexanderLanin]

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.

[pawelrutkaq]

isnt REPO_RUNNER_LABELS for that ?

[MTomBosch]

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 ;)