Feature request: Action runner priority #11641

New Issue

GiteaMirror · 2025-11-02T09:43:15-06:00

GiteaMirror commented

2025-11-02 09:43:15 -06:00

Originally created by @PatrLind on GitHub (Sep 12, 2023).

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

Originally created by @PatrLind on GitHub (Sep 12, 2023). ### 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_

GiteaMirror added the topic/gitea-actions type/proposal issue/workaround labels 2025-11-02 09:43:15 -06:00

GiteaMirror commented

2025-11-02 09:43:16 -06:00

@haydonryan commented on GitHub (Oct 16, 2024):

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.

@haydonryan commented on GitHub (Oct 16, 2024): 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.

GiteaMirror commented

2025-11-02 09:43:16 -06:00

@mtdcy commented on GitHub (Jan 3, 2025):

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

@mtdcy commented on GitHub (Jan 3, 2025): there is a workarround: create multiple runner instances on your perferred machine.

GiteaMirror commented

2025-11-02 09:43:16 -06:00

@lunny commented on GitHub (Jan 3, 2025):

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.

@lunny commented on GitHub (Jan 3, 2025): A workaround is to change the act_runner's fetch interval. ```ini 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.

GiteaMirror commented

2025-11-02 09:43:16 -06:00

@mtdcy commented on GitHub (Jan 4, 2025):

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.

@mtdcy commented on GitHub (Jan 4, 2025): > A workaround is to change the act_runner's fetch interval. > > ```ini > 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.

GiteaMirror commented

2025-11-02 09:43:17 -06:00

@lunny commented on GitHub (Jan 4, 2025):

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.

@lunny commented on GitHub (Jan 4, 2025): > > A workaround is to change the act_runner's fetch interval. > > ```ini > > 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.

GiteaMirror commented

2025-11-02 09:43:17 -06:00

@mtdcy commented on GitHub (Jan 4, 2025):

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
https://github.com/go-gitea/gitea/issues/27042#issuecomment-2570279905,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD3HOMGM2B4KNNFIG2CTS4T2I55YDAVCNFSM6AAAAABQBJDC5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZQGI3TSOJQGU
.
You are receiving this because you commented.Message ID:
@.***>

@mtdcy commented on GitHub (Jan 4, 2025): 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 > <https://github.com/go-gitea/gitea/issues/27042#issuecomment-2570279905>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AD3HOMGM2B4KNNFIG2CTS4T2I55YDAVCNFSM6AAAAABQBJDC5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZQGI3TSOJQGU> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

GiteaMirror commented

2025-11-02 09:43:17 -06:00

@lunny commented on GitHub (Jan 4, 2025):

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.

@lunny commented on GitHub (Jan 4, 2025): > 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)](https://github.com/go-gitea/gitea/issues/27042#issuecomment-2570279905)>, 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.

GiteaMirror commented

2025-11-02 09:43:17 -06:00

@bencurio commented on GitHub (Jan 7, 2025):

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.

@bencurio commented on GitHub (Jan 7, 2025): 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.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#11641