Priority for self-hosted runners

[taschik]

Hi,

I have several self-hosted runners (8 cores, and 4 cores machines) and would like to make sure that some machines are prioritized over others because these machines have stronger hardware.

I am not sure tags are the right way to go here because I’d like to have all different jobs always prefer the group with 8 cores and only use the 4-core machines when there are no “fast” ones available.

Any idea how to do that?

Thanks

[BrightRan]

@taschik,

I am not sure tags are the right way to go here because I’d like to have all different jobs always prefer the group with 8 cores and only use the 4-core machines when there are no “fast” ones available.

If you set a job to run on the self-hosted runner with a specified label, the job will only use the available runners that have the specified label.

By default, the repository runners have the priority to be used for the workflow jobs in a repository. If there is not available repository runners, the jobs will check Organization runners. To view more details, you can see “Routing precedence for self-hosted runners”.

In your case, as a workaround, you can install the 8 cores runners as the repository runners and 4 cores runners as the Organization runners. More details, see “Adding self-hosted runners”.

[taschik]

Thanks @brightran for the reply. This would work for just two different classes of runners but is not viable anymore with more. On systems like Buildkite, you can configure a priority in combination with tags. It would be great to have this ability with self-hosted runners too. Perhaps a feature request?

[gajus]

Same problem here. We are dynamically provisioning / removing workers based on their activity. The problem is that because workloads are randomized, a lot more workers are live than there could be.

[gajus]

Looks like the above behavior is no longer active:

We are changing that behavior so that the first available matching runner at any level will run the job in all cases. This allows jobs to be sent to self-hosted runners much faster, especially for organizations and enterprises with lots of self-hosted runners.

  <a href="https://github.blog/changelog/2022-01-04-github-actions-changing-the-search-order-for-self-hosted-runners/" target="_blank" rel="noopener nofollow ugc">The GitHub Blog</a>

GitHub Actions: Changing the search order for self-hosted runners | GitHub...

GitHub Actions: Changing the search order for self-hosted runners

[jupe]

It seems that we’re moving away from the original intention of prioritization. Previously, we could prioritize jobs using repository-specific runners, but that option is no longer available. Having a “runner priority feature” is essential for our setup, particularly for effectively utilizing specific runners when using bare-metal machines.

While in cloud environments, machine consolidation is simpler, our local lab setup requires a different approach. Hardware updates are done gradually, with older machines being replaced as newer ones come in. This results in a pool with hardware from 2-3 different generations. Prioritizing these newer machines would maximize performance and deliver the best experience to end users.

[marcelmedeiros1]

Imagine that I have 3k minutes free in my Github plan to use GitHub Hosted runners. Is there a way to configure my workflows so that it will prioritize the Github-hosted, and after the free minutes expire the self-hosted runners run every workflow?