Feature request: Action runner priority

[PatrLind]

Feature Description

I would like to be able to set the priority on an action runner.

I have several runners that run on hardware with quite different performance and I would like to set a priority number for my runners so that the runner with the highest priority always runs first. If that runner is not available then the runner with the next lowest priority should get the job. My runners are also not always online, so maybe my high performance runner is only online parts of the day, but my standard performance runners are always online.

Screenshots

No response

[haydonryan]

Totally agree with this. I think it would be an awesome feature.
I have gitea running on my synology nas and a runner there. Being able to have a runner also on my desktop that would take priority when it's on would be great. Ultimately we all want faster feedback loops.

[mtdcy]

there is a workarround: create multiple runner instances on your perferred machine.

[lunny]

A workaround is to change the act_runner's fetch interval.

runner:
  # The interval for fetching the job from the Gitea instance.
  fetch_interval: 2s

High priority runner should have small interval time, low priority runner should have big interval time.

[mtdcy]

A workaround is to change the act_runner's fetch interval.

runner:
  # The interval for fetching the job from the Gitea instance.
  fetch_interval: 2s

High priority runner should have small interval time, low priority runner should have big interval time.

I'm not sure this parameter will work or not, as I known the capacity parameter does not work at all.

If it works, combine with multiple instances, it will be the best workarround.

[lunny]

A workaround is to change the act_runner's fetch interval.

runner:
  # The interval for fetching the job from the Gitea instance.
  fetch_interval: 2s

High priority runner should have small interval time, low priority runner should have big interval time.

I'm not sure this parameter will work or not, as I known the capacity parameter does not work at all.

Is there any issue with that?

If it works, combine with multiple instances, it will be the best workarround.

[mtdcy]

Lunny Xiao ***@***.***>于2025年1月4日 周六14:30写道：

A workaround is to change the act_runner's fetch interval. runner: # The interval for fetching the job from the Gitea instance. fetch_interval: 2s High priority runner should have small interval time, low priority runner should have big interval time. I'm not sure this parameter will work or not, as I known the capacity parameter does not work at all. Is there any issue with that? If it works, combine with multiple instances, it will be the best workarround. —

I think this is off topic，or you can test it.

…

Reply to this email directly, view it on GitHub <#27042 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD3HOMGM2B4KNNFIG2CTS4T2I55YDAVCNFSM6AAAAABQBJDC5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZQGI3TSOJQGU> . You are receiving this because you commented.Message ID: ***@***.***>

[lunny]

Lunny Xiao @.>于2025年1月4日 周六14:30写道：
A workaround is to change the act_runner's fetch interval. runner: # The interval for fetching the job from the Gitea instance. fetch_interval: 2s High priority runner should have small interval time, low priority runner should have big interval time. I'm not sure this parameter will work or not, as I known the capacity parameter does not work at all. Is there any issue with that? If it works, combine with multiple instances, it will be the best workarround. —
I think this is off topic，or you can test it.
…
Reply to this email directly, view it on GitHub <#27042 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD3HOMGM2B4KNNFIG2CTS4T2I55YDAVCNFSM6AAAAABQBJDC5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZQGI3TSOJQGU . You are receiving this because you commented.Message ID: @.>

I have tested it and it works well for me.

[bencurio]

Currently, I am also using it this way, and it works. In most cases, the job is picked up by the Runner that has a lower fetch_interval value. The global runner is set to around 10s, while the organization runner is set to 2s.

However, it might be worth considering prioritizing based on the type of runner: user -> org -> global.

In this setup, if the user runner is active, jobs will be assigned there as long as it has capacity, then to the organization runner, and finally to the global runner.