👏

bump

Unlike the legacy actions-runner-controller, periodic reconciliation of resources is practically disabled in the new controller due to WithEventFilter(predicate.ResourceVersionChangedPredicate{}).
To know if a scheduled override should take place, periodic reconciliation must occur for the AutoscalingRunnerSet resource in one way or another.
In order to make it work here, I used Result.RequeueAfter, and it indeed worked fine, but I believe that going with a standard sync period could eliminate potential scenarios of missing an override due to a bug in the reconciliation logic.

So a small question for the maintainers -
What was the reason behind ignoring the resync period in the gha-runner-scale-set-controller? And if the concern is overloading the controller when many resources exist, won't it make sense to enable it just for the AutoscalingRunnerSet resource?
I'd love to know.

Hi @nikola-jokic
I can see you're the most active code owner here. Is there anything else needed to push this forward?

Bump on this one, really needed feature

Hey team, do we have an ETA on this? P+ customer Itaú is asking for a status.

Hi Team, any update on this? We met with the customer today.

It would be nice to have a position on this. If it is going to be merged or not. This way we could define what to do to tackle this issue in our clusters.

👋🏽 Any chance we get any sort of feedback on this PR? This is a very important feature for cost management

@asafhm Thoughts on also supporting cronOverrides with:

apiVersion: actions.github.com/v1alpha1
kind: AutoscalingRunnerSet
metadata:
  annotations: # abbreviated
  labels: # abbreviated
  name: example-gha-runner-scale-set
spec:
  githubConfigSecret: "<some_value>"
  githubConfigUrl: "<some_value>"
  maxRunners: 2
  minRunners: 1
  cronOverrides:
  -  timezone: America/Chicago
      start: 0 6 * * *        # At 6:00 AM
      end: 0 20 * * *        # At 8:00 PM
      minRunners: 0

My main usecase is to have 0 minRunners over the weekend for example.

@asafhm Thoughts on also supporting cronOverrides with:

apiVersion: actions.github.com/v1alpha1
kind: AutoscalingRunnerSet
metadata:
  annotations: # abbreviated
  labels: # abbreviated
  name: example-gha-runner-scale-set
spec:
  githubConfigSecret: "<some_value>"
  githubConfigUrl: "<some_value>"
  maxRunners: 2
  minRunners: 1
  cronOverrides:
  -  timezone: America/Chicago
      start: 0 6 * * *        # At 6:00 AM
      end: 0 20 * * *        # At 8:00 PM
      minRunners: 0

My main usecase is to have 0 minRunners over the weekend for example.

@pragmaticivan You could achieve this with scheduledOverrides too, like this:

  # Scale down on weekends (Friday 6pm - Monday 8am America/Chicago time)
  - startTime: "2024-11-22T18:00:00-06:00"
    endTime: "2024-11-25T08:00:00-06:00"
    recurrenceRule:
      frequency: Weekly
    minRunners: 0

The advantage here is that you can be specific about the future starting point of this rule up to the date itself, which is impossible using Cron, since it will start from the next match of its pattern. I suppose there may be use cases that require specificity for some.

Honestly, it appears that this repository in its entirety is not actively maintained anymore, and for the past two months all commits came from bots, regardless of the large amount of PRs waiting to be looked at.
That is unfortunate, given the obvious need here for this feature, and the popularity of self-hosted runners on Kubernetes in itself...

I know that many people take their holidays in September and October, so I guess there's no way around it, but they don't come back very quickly. 😢

I know that many people take their holidays in September and October, so I guess there's no way around it, but they don't come back very quickly. 😢

Sadly this trend began before September, and even before this PR was created :/

@Link- Trying my luck here since no other maintainer appears active recently... Could I kindly solicit a review? There's enough demand from the community for this PR

Bump

I've given up hope this or any other long-living PR by the community will eventually get merged.
For those here who still need a workaround, there's an operator named kube-green that seems nice and may help. It doesn't appear to be too complex and doesn't support scenarios of specific dates for scaling down, but if your use case is to scale down your runners on weekends/out-of-office hours, you should be fine.
I haven't tried it myself since my situation with ARC changed over the last several weeks, but you can use its custom patches capability to support Custom Resources such as AutoscalingRunnerSet.

@nikola-jokic Would it be possible to get a review on this please?

Hey team! Any reason why this was not merged in the release from today? It would be nice to have at least a position on this, an approval or rejection.