2021-02-07 17:37:27 +09:00
/ *
Copyright 2020 The actions - runner - controller authors .
Licensed under the Apache License , Version 2.0 ( the "License" ) ;
you may not use this file except in compliance with the License .
You may obtain a copy of the License at
http : //www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing , software
distributed under the License is distributed on an "AS IS" BASIS ,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND , either express or implied .
See the License for the specific language governing permissions and
limitations under the License .
* /
package controllers
import (
"context"
2021-11-09 09:04:19 +09:00
"encoding/json"
2021-02-07 17:37:27 +09:00
"fmt"
2022-09-20 20:08:22 -04:00
"io"
2021-02-07 17:37:27 +09:00
"net/http"
2021-02-23 08:05:25 +09:00
"strings"
2022-06-27 18:31:48 +09:00
"sync"
2021-02-07 17:37:27 +09:00
"time"
2021-05-11 06:40:53 +00:00
"k8s.io/apimachinery/pkg/types"
"sigs.k8s.io/controller-runtime/pkg/reconcile"
2021-02-07 17:37:27 +09:00
"github.com/go-logr/logr"
2022-08-24 13:08:40 +09:00
gogithub "github.com/google/go-github/v47/github"
2021-02-07 17:37:27 +09:00
"k8s.io/apimachinery/pkg/runtime"
"k8s.io/client-go/tools/record"
ctrl "sigs.k8s.io/controller-runtime"
"sigs.k8s.io/controller-runtime/pkg/client"
2021-06-22 17:55:06 +09:00
"github.com/actions-runner-controller/actions-runner-controller/api/v1alpha1"
2021-12-19 01:29:44 -08:00
"github.com/actions-runner-controller/actions-runner-controller/github"
2022-02-16 02:08:56 -08:00
"github.com/actions-runner-controller/actions-runner-controller/simulator"
2021-02-07 17:37:27 +09:00
)
const (
scaleTargetKey = "scaleTarget"
2021-11-09 09:04:19 +09:00
keyPrefixEnterprise = "enterprises/"
2021-12-19 01:29:44 -08:00
keyRunnerGroup = "/group/"
2022-06-27 18:31:48 +09:00
DefaultQueueLimit = 100
2021-02-07 17:37:27 +09:00
)
// HorizontalRunnerAutoscalerGitHubWebhook autoscales a HorizontalRunnerAutoscaler and the RunnerDeployment on each
// GitHub Webhook received
type HorizontalRunnerAutoscalerGitHubWebhook struct {
client . Client
Log logr . Logger
Recorder record . EventRecorder
Scheme * runtime . Scheme
// SecretKeyBytes is the byte representation of the Webhook secret token
// the administrator is generated and specified in GitHub Web UI.
SecretKeyBytes [ ] byte
2021-12-19 01:29:44 -08:00
// GitHub Client to discover runner groups assigned to a repository
GitHubClient * github . Client
2021-03-09 09:12:46 +09:00
// Namespace is the namespace to watch for HorizontalRunnerAutoscaler's to be
2021-02-07 17:37:27 +09:00
// scaled on Webhook.
// Set to empty for letting it watch for all namespaces.
2021-03-09 09:12:46 +09:00
Namespace string
Name string
2022-06-27 18:31:48 +09:00
// QueueLimit is the maximum length of the bounded queue of scale targets and their associated operations
// A scale target is enqueued on each retrieval of each eligible webhook event, so that it is processed asynchronously.
QueueLimit int
2022-09-20 20:08:22 -04:00
worker * worker
workerInit sync . Once
2021-02-07 17:37:27 +09:00
}
2021-06-22 17:10:09 +09:00
func ( autoscaler * HorizontalRunnerAutoscalerGitHubWebhook ) Reconcile ( _ context . Context , request reconcile . Request ) ( reconcile . Result , error ) {
2021-02-07 17:37:27 +09:00
return ctrl . Result { } , nil
}
// +kubebuilder:rbac:groups=actions.summerwind.dev,resources=horizontalrunnerautoscalers,verbs=get;list;watch;create;update;patch;delete
// +kubebuilder:rbac:groups=actions.summerwind.dev,resources=horizontalrunnerautoscalers/finalizers,verbs=get;list;watch;create;update;patch;delete
// +kubebuilder:rbac:groups=actions.summerwind.dev,resources=horizontalrunnerautoscalers/status,verbs=get;update;patch
// +kubebuilder:rbac:groups=core,resources=events,verbs=create;patch
func ( autoscaler * HorizontalRunnerAutoscalerGitHubWebhook ) Handle ( w http . ResponseWriter , r * http . Request ) {
var (
ok bool
err error
)
defer func ( ) {
if ! ok {
w . WriteHeader ( http . StatusInternalServerError )
if err != nil {
msg := err . Error ( )
if written , err := w . Write ( [ ] byte ( msg ) ) ; err != nil {
2022-02-17 09:15:26 +09:00
autoscaler . Log . V ( 1 ) . Error ( err , "failed writing http error response" , "msg" , msg , "written" , written )
2021-02-07 17:37:27 +09:00
}
}
}
} ( )
defer func ( ) {
if r . Body != nil {
r . Body . Close ( )
}
} ( )
2021-03-08 23:46:27 +00:00
// respond ok to GET / e.g. for health check
if r . Method == http . MethodGet {
2021-11-09 02:07:07 +02:00
ok = true
2021-03-08 23:46:27 +00:00
fmt . Fprintln ( w , "webhook server is running" )
return
}
2021-02-07 17:37:27 +09:00
var payload [ ] byte
if len ( autoscaler . SecretKeyBytes ) > 0 {
payload , err = gogithub . ValidatePayload ( r , autoscaler . SecretKeyBytes )
if err != nil {
autoscaler . Log . Error ( err , "error validating request body" )
return
}
} else {
2022-09-20 20:08:22 -04:00
payload , err = io . ReadAll ( r . Body )
2021-02-07 17:37:27 +09:00
if err != nil {
autoscaler . Log . Error ( err , "error reading request body" )
return
}
}
webhookType := gogithub . WebHookType ( r )
event , err := gogithub . ParseWebHook ( webhookType , payload )
if err != nil {
var s string
if payload != nil {
s = string ( payload )
}
autoscaler . Log . Error ( err , "could not parse webhook" , "webhookType" , webhookType , "payload" , s )
return
}
var target * ScaleTarget
2021-02-25 10:07:41 +09:00
log := autoscaler . Log . WithValues (
"event" , webhookType ,
"hookID" , r . Header . Get ( "X-GitHub-Hook-ID" ) ,
"delivery" , r . Header . Get ( "X-GitHub-Delivery" ) ,
)
2021-02-07 17:37:27 +09:00
2021-11-09 09:04:19 +09:00
var enterpriseEvent struct {
Enterprise struct {
Slug string ` json:"slug,omitempty" `
} ` json:"enterprise,omitempty" `
}
if err := json . Unmarshal ( payload , & enterpriseEvent ) ; err != nil {
var s string
if payload != nil {
s = string ( payload )
}
autoscaler . Log . Error ( err , "could not parse webhook payload for extracting enterprise slug" , "webhookType" , webhookType , "payload" , s )
}
enterpriseSlug := enterpriseEvent . Enterprise . Slug
2021-02-07 17:37:27 +09:00
switch e := event . ( type ) {
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
case * gogithub . WorkflowJobEvent :
if workflowJob := e . GetWorkflowJob ( ) ; workflowJob != nil {
log = log . WithValues (
"workflowJob.status" , workflowJob . GetStatus ( ) ,
"workflowJob.labels" , workflowJob . Labels ,
"repository.name" , e . Repo . GetName ( ) ,
"repository.owner.login" , e . Repo . Owner . GetLogin ( ) ,
"repository.owner.type" , e . Repo . Owner . GetType ( ) ,
2021-11-09 09:04:19 +09:00
"enterprise.slug" , enterpriseSlug ,
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
"action" , e . GetAction ( ) ,
2022-11-04 01:46:58 +00:00
"workflowJob.runID" , e . WorkflowJob . GetRunID ( ) ,
"workflowJob.ID" , e . WorkflowJob . GetID ( ) ,
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
)
}
labels := e . WorkflowJob . Labels
2021-11-09 09:05:50 +09:00
switch action := e . GetAction ( ) ; action {
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
case "queued" , "completed" :
target , err = autoscaler . getJobScaleUpTargetForRepoOrOrg (
context . TODO ( ) ,
log ,
e . Repo . GetName ( ) ,
e . Repo . Owner . GetLogin ( ) ,
e . Repo . Owner . GetType ( ) ,
2021-11-09 09:04:19 +09:00
enterpriseSlug ,
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
labels ,
)
2022-04-13 07:53:07 +08:00
if target == nil {
break
}
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
2022-04-13 07:53:07 +08:00
if e . GetAction ( ) == "queued" {
target . Amount = 1
break
} else if e . GetAction ( ) == "completed" && e . GetWorkflowJob ( ) . GetConclusion ( ) != "skipped" {
// A nagative amount is processed in the tryScale func as a scale-down request,
// that erasese the oldest CapacityReservation with the same amount.
// If the first CapacityReservation was with Replicas=1, this negative scale target erases that,
// so that the resulting desired replicas decreases by 1.
target . Amount = - 1
break
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
}
2022-04-13 07:53:07 +08:00
// If the conclusion is "skipped", we will ignore it and fallthrough to the default case.
fallthrough
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
default :
2021-11-09 09:05:50 +09:00
ok = true
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
2021-11-09 09:05:50 +09:00
w . WriteHeader ( http . StatusOK )
log . V ( 2 ) . Info ( "Received and ignored a workflow_job event as it triggers neither scale-up nor scale-down" , "action" , action )
return
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
}
2021-02-07 17:37:27 +09:00
case * gogithub . PingEvent :
ok = true
w . WriteHeader ( http . StatusOK )
msg := "pong"
if written , err := w . Write ( [ ] byte ( msg ) ) ; err != nil {
2021-02-25 10:07:41 +09:00
log . Error ( err , "failed writing http response" , "msg" , msg , "written" , written )
2021-02-07 17:37:27 +09:00
}
2021-02-25 10:07:41 +09:00
log . Info ( "received ping event" )
2021-02-07 17:37:27 +09:00
return
default :
2021-02-25 10:07:41 +09:00
log . Info ( "unknown event type" , "eventType" , webhookType )
2021-02-07 17:37:27 +09:00
return
}
if err != nil {
2021-02-25 10:07:41 +09:00
log . Error ( err , "handling check_run event" )
2021-02-07 17:37:27 +09:00
return
}
if target == nil {
2022-02-17 09:15:26 +09:00
log . V ( 1 ) . Info (
2022-12-11 23:39:04 +00:00
"Scale target not found. If this is unexpected, ensure that there is exactly one repository-wide or organizational runner deployment that matches this webhook event. If --watch-namespace is set ensure this is configured correctly." ,
2021-03-10 09:40:44 +09:00
)
2021-02-07 17:37:27 +09:00
2021-03-10 09:40:44 +09:00
msg := "no horizontalrunnerautoscaler to scale for this github event"
2021-02-07 17:37:27 +09:00
ok = true
w . WriteHeader ( http . StatusOK )
if written , err := w . Write ( [ ] byte ( msg ) ) ; err != nil {
2021-02-25 10:07:41 +09:00
log . Error ( err , "failed writing http response" , "msg" , msg , "written" , written )
2021-02-07 17:37:27 +09:00
}
return
}
2022-06-27 18:31:48 +09:00
autoscaler . workerInit . Do ( func ( ) {
batchScaler := newBatchScaler ( context . Background ( ) , autoscaler . Client , autoscaler . Log )
queueLimit := autoscaler . QueueLimit
if queueLimit == 0 {
queueLimit = DefaultQueueLimit
}
autoscaler . worker = newWorker ( context . Background ( ) , queueLimit , batchScaler . Add )
} )
2021-02-07 17:37:27 +09:00
2022-06-27 18:31:48 +09:00
target . log = & log
if ok := autoscaler . worker . Add ( target ) ; ! ok {
log . Error ( err , "Could not scale up due to queue full" )
2021-02-07 17:37:27 +09:00
return
}
ok = true
w . WriteHeader ( http . StatusOK )
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
msg := fmt . Sprintf ( "scaled %s by %d" , target . Name , target . Amount )
2021-02-07 17:37:27 +09:00
2022-11-04 01:46:58 +00:00
log . Info ( msg )
2021-02-07 17:37:27 +09:00
if written , err := w . Write ( [ ] byte ( msg ) ) ; err != nil {
2021-02-25 10:07:41 +09:00
log . Error ( err , "failed writing http response" , "msg" , msg , "written" , written )
2021-02-07 17:37:27 +09:00
}
}
func ( autoscaler * HorizontalRunnerAutoscalerGitHubWebhook ) findHRAsByKey ( ctx context . Context , value string ) ( [ ] v1alpha1 . HorizontalRunnerAutoscaler , error ) {
2021-03-09 09:12:46 +09:00
ns := autoscaler . Namespace
2021-02-07 17:37:27 +09:00
var defaultListOpts [ ] client . ListOption
if ns != "" {
defaultListOpts = append ( defaultListOpts , client . InNamespace ( ns ) )
}
var hras [ ] v1alpha1 . HorizontalRunnerAutoscaler
if value != "" {
opts := append ( [ ] client . ListOption { } , defaultListOpts ... )
opts = append ( opts , client . MatchingFields { scaleTargetKey : value } )
2021-03-09 09:12:46 +09:00
if autoscaler . Namespace != "" {
opts = append ( opts , client . InNamespace ( autoscaler . Namespace ) )
2021-02-23 08:05:25 +09:00
}
2021-02-07 17:37:27 +09:00
var hraList v1alpha1 . HorizontalRunnerAutoscalerList
if err := autoscaler . List ( ctx , & hraList , opts ... ) ; err != nil {
return nil , err
}
2022-02-23 08:29:13 -08:00
hras = append ( hras , hraList . Items ... )
2021-02-07 17:37:27 +09:00
}
return hras , nil
}
func matchTriggerConditionAgainstEvent ( types [ ] string , eventAction * string ) bool {
if len ( types ) == 0 {
return true
}
if eventAction == nil {
return false
}
for _ , tpe := range types {
if tpe == * eventAction {
return true
}
}
return false
}
type ScaleTarget struct {
v1alpha1 . HorizontalRunnerAutoscaler
v1alpha1 . ScaleUpTrigger
2022-06-27 18:31:48 +09:00
log * logr . Logger
2021-02-07 17:37:27 +09:00
}
func ( autoscaler * HorizontalRunnerAutoscalerGitHubWebhook ) searchScaleTargets ( hras [ ] v1alpha1 . HorizontalRunnerAutoscaler , f func ( v1alpha1 . ScaleUpTrigger ) bool ) [ ] ScaleTarget {
var matched [ ] ScaleTarget
for _ , hra := range hras {
if ! hra . ObjectMeta . DeletionTimestamp . IsZero ( ) {
continue
}
for _ , scaleUpTrigger := range hra . Spec . ScaleUpTriggers {
if ! f ( scaleUpTrigger ) {
continue
}
matched = append ( matched , ScaleTarget {
HorizontalRunnerAutoscaler : hra ,
ScaleUpTrigger : scaleUpTrigger ,
} )
}
}
return matched
}
func ( autoscaler * HorizontalRunnerAutoscalerGitHubWebhook ) getScaleTarget ( ctx context . Context , name string , f func ( v1alpha1 . ScaleUpTrigger ) bool ) ( * ScaleTarget , error ) {
hras , err := autoscaler . findHRAsByKey ( ctx , name )
if err != nil {
return nil , err
}
2021-05-11 06:40:53 +00:00
autoscaler . Log . V ( 1 ) . Info ( fmt . Sprintf ( "Found %d HRAs by key" , len ( hras ) ) , "key" , name )
2021-02-07 17:37:27 +09:00
targets := autoscaler . searchScaleTargets ( hras , f )
2021-02-25 10:07:41 +09:00
n := len ( targets )
if n == 0 {
return nil , nil
}
if n > 1 {
2021-02-23 08:05:25 +09:00
var scaleTargetIDs [ ] string
for _ , t := range targets {
scaleTargetIDs = append ( scaleTargetIDs , t . HorizontalRunnerAutoscaler . Name )
}
autoscaler . Log . Info (
"Found too many scale targets: " +
"It must be exactly one to avoid ambiguity. " +
2021-03-09 09:12:46 +09:00
"Either set Namespace for the webhook-based autoscaler to let it only find HRAs in the namespace, " +
2021-11-09 09:04:19 +09:00
"or update Repository, Organization, or Enterprise fields in your RunnerDeployment resources to fix the ambiguity." ,
2021-02-23 08:05:25 +09:00
"scaleTargets" , strings . Join ( scaleTargetIDs , "," ) )
2021-02-07 17:37:27 +09:00
return nil , nil
}
return & targets [ 0 ] , nil
}
2021-11-09 09:04:19 +09:00
func ( autoscaler * HorizontalRunnerAutoscalerGitHubWebhook ) getScaleUpTarget ( ctx context . Context , log logr . Logger , repo , owner , ownerType , enterprise string , f func ( v1alpha1 . ScaleUpTrigger ) bool ) ( * ScaleTarget , error ) {
2021-12-19 01:29:44 -08:00
scaleTarget := func ( value string ) ( * ScaleTarget , error ) {
return autoscaler . getScaleTarget ( ctx , value , f )
}
return autoscaler . getScaleUpTargetWithFunction ( ctx , log , repo , owner , ownerType , enterprise , scaleTarget )
}
func ( autoscaler * HorizontalRunnerAutoscalerGitHubWebhook ) getJobScaleUpTargetForRepoOrOrg (
ctx context . Context , log logr . Logger , repo , owner , ownerType , enterprise string , labels [ ] string ,
) ( * ScaleTarget , error ) {
scaleTarget := func ( value string ) ( * ScaleTarget , error ) {
return autoscaler . getJobScaleTarget ( ctx , value , labels )
}
return autoscaler . getScaleUpTargetWithFunction ( ctx , log , repo , owner , ownerType , enterprise , scaleTarget )
}
func ( autoscaler * HorizontalRunnerAutoscalerGitHubWebhook ) getScaleUpTargetWithFunction (
ctx context . Context , log logr . Logger , repo , owner , ownerType , enterprise string , scaleTarget func ( value string ) ( * ScaleTarget , error ) ) ( * ScaleTarget , error ) {
2021-02-23 08:05:25 +09:00
repositoryRunnerKey := owner + "/" + repo
2021-12-19 01:29:44 -08:00
// Search for repository HRAs
if target , err := scaleTarget ( repositoryRunnerKey ) ; err != nil {
log . Error ( err , "finding repository-wide runner" , "repository" , repositoryRunnerKey )
2021-02-07 17:37:27 +09:00
return nil , err
} else if target != nil {
2021-12-19 01:29:44 -08:00
log . Info ( "job scale up target is repository-wide runners" , "repository" , repo )
2021-02-07 17:37:27 +09:00
return target , nil
}
2021-02-23 08:05:25 +09:00
if ownerType == "User" {
2021-12-19 01:29:44 -08:00
log . V ( 1 ) . Info ( "user repositories not supported" , "owner" , owner )
2021-02-23 08:05:25 +09:00
return nil , nil
}
2022-02-16 02:08:56 -08:00
// Find the potential runner groups first to avoid spending API queries needless. Once/if GitHub improves an
2021-12-19 01:29:44 -08:00
// API to find related/linked runner groups from a specific repository this logic could be removed
2022-02-16 02:08:56 -08:00
managedRunnerGroups , err := autoscaler . getManagedRunnerGroupsFromHRAs ( ctx , enterprise , owner )
2021-12-19 01:29:44 -08:00
if err != nil {
2022-02-16 02:08:56 -08:00
log . Error ( err , "finding potential organization/enterprise runner groups from HRAs" , "organization" , owner )
2021-11-09 09:04:19 +09:00
return nil , err
2021-12-19 01:29:44 -08:00
}
2022-02-16 02:08:56 -08:00
if managedRunnerGroups . IsEmpty ( ) {
2021-11-09 09:04:19 +09:00
log . V ( 1 ) . Info ( "no repository/organizational/enterprise runner found" ,
"repository" , repositoryRunnerKey ,
"organization" , owner ,
"enterprises" , enterprise ,
)
2022-02-17 09:15:26 +09:00
} else {
log . V ( 1 ) . Info ( "Found some runner groups are managed by ARC" , "groups" , managedRunnerGroups )
2021-02-07 17:37:27 +09:00
}
2022-02-16 02:08:56 -08:00
var visibleGroups * simulator . VisibleRunnerGroups
2021-12-19 01:29:44 -08:00
if autoscaler . GitHubClient != nil {
2022-02-16 02:08:56 -08:00
simu := & simulator . Simulator {
Client : autoscaler . GitHubClient ,
2022-07-04 20:17:09 +09:00
Log : log ,
2022-02-16 02:08:56 -08:00
}
2021-12-19 01:29:44 -08:00
// Get available organization runner groups and enterprise runner groups for a repository
2022-02-16 02:08:56 -08:00
// These are the sum of runner groups with repository access = All repositories and runner groups
// where owner/repo has access to as well. The list will include default runner group also if it has access to
visibleGroups , err = simu . GetRunnerGroupsVisibleToRepository ( ctx , owner , repositoryRunnerKey , managedRunnerGroups )
log . V ( 1 ) . Info ( "Searching in runner groups" , "groups" , visibleGroups )
2021-12-19 01:29:44 -08:00
if err != nil {
log . Error ( err , "Unable to find runner groups from repository" , "organization" , owner , "repository" , repo )
2022-02-16 02:08:56 -08:00
return nil , fmt . Errorf ( "error while finding visible runner groups: %v" , err )
2021-12-19 01:29:44 -08:00
}
} else {
// For backwards compatibility if GitHub authentication is not configured, we assume all runner groups have
// visibility=all to honor the previous implementation, therefore any available enterprise/organization runner
2022-02-16 02:08:56 -08:00
// is a potential target for scaling. This will also avoid doing extra API calls caused by
// GitHubClient.GetRunnerGroupsVisibleToRepository in case users are not using custom visibility on their runner
// groups or they are using only default runner groups
visibleGroups = managedRunnerGroups
}
scaleTargetKey := func ( rg simulator . RunnerGroup ) string {
switch rg . Kind {
case simulator . Default :
switch rg . Scope {
case simulator . Organization :
return owner
case simulator . Enterprise :
return enterpriseKey ( enterprise )
}
case simulator . Custom :
switch rg . Scope {
case simulator . Organization :
return organizationalRunnerGroupKey ( owner , rg . Name )
case simulator . Enterprise :
return enterpriseRunnerGroupKey ( enterprise , rg . Name )
}
}
return ""
2021-12-19 01:29:44 -08:00
}
2021-02-07 17:37:27 +09:00
2022-02-17 09:15:26 +09:00
log . V ( 1 ) . Info ( "groups" , "groups" , visibleGroups )
2022-02-16 02:08:56 -08:00
var t * ScaleTarget
traverseErr := visibleGroups . Traverse ( func ( rg simulator . RunnerGroup ) ( bool , error ) {
key := scaleTargetKey ( rg )
target , err := scaleTarget ( key )
if err != nil {
log . Error ( err , "finding runner group" , "enterprise" , enterprise , "organization" , owner , "repository" , repo , "key" , key )
return false , err
} else if target == nil {
return false , nil
2021-12-19 01:29:44 -08:00
}
2022-02-16 02:08:56 -08:00
t = target
2022-02-17 09:15:26 +09:00
log . V ( 1 ) . Info ( "job scale up target found" , "enterprise" , enterprise , "organization" , owner , "repository" , repo , "key" , key )
2022-02-16 02:08:56 -08:00
return true , nil
} )
if traverseErr != nil {
return nil , err
2021-12-19 01:29:44 -08:00
}
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
2022-02-16 02:08:56 -08:00
if t == nil {
log . V ( 1 ) . Info ( "no repository/organizational/enterprise runner found" ,
"repository" , repositoryRunnerKey ,
"organization" , owner ,
"enterprise" , enterprise ,
)
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
}
2022-02-16 02:08:56 -08:00
return t , nil
2021-12-19 01:29:44 -08:00
}
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
2022-02-16 02:08:56 -08:00
func ( autoscaler * HorizontalRunnerAutoscalerGitHubWebhook ) getManagedRunnerGroupsFromHRAs ( ctx context . Context , enterprise , org string ) ( * simulator . VisibleRunnerGroups , error ) {
groups := simulator . NewVisibleRunnerGroups ( )
2021-12-19 01:29:44 -08:00
ns := autoscaler . Namespace
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
2021-12-19 01:29:44 -08:00
var defaultListOpts [ ] client . ListOption
if ns != "" {
defaultListOpts = append ( defaultListOpts , client . InNamespace ( ns ) )
2021-11-09 09:04:19 +09:00
}
2021-12-19 01:29:44 -08:00
opts := append ( [ ] client . ListOption { } , defaultListOpts ... )
if autoscaler . Namespace != "" {
opts = append ( opts , client . InNamespace ( autoscaler . Namespace ) )
2021-11-09 09:04:19 +09:00
}
2021-12-19 01:29:44 -08:00
var hraList v1alpha1 . HorizontalRunnerAutoscalerList
if err := autoscaler . List ( ctx , & hraList , opts ... ) ; err != nil {
2022-02-16 02:08:56 -08:00
return groups , err
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
}
2021-12-19 01:29:44 -08:00
for _ , hra := range hraList . Items {
2022-02-16 02:08:56 -08:00
var o , e , g string
kind := hra . Spec . ScaleTargetRef . Kind
switch kind {
2021-12-19 01:29:44 -08:00
case "RunnerSet" :
var rs v1alpha1 . RunnerSet
if err := autoscaler . Client . Get ( context . Background ( ) , types . NamespacedName { Namespace : hra . Namespace , Name : hra . Spec . ScaleTargetRef . Name } , & rs ) ; err != nil {
2022-02-16 02:08:56 -08:00
return groups , err
2021-12-19 01:29:44 -08:00
}
2022-02-16 02:08:56 -08:00
o , e , g = rs . Spec . Organization , rs . Spec . Enterprise , rs . Spec . Group
2021-12-19 01:29:44 -08:00
case "RunnerDeployment" , "" :
var rd v1alpha1 . RunnerDeployment
if err := autoscaler . Client . Get ( context . Background ( ) , types . NamespacedName { Namespace : hra . Namespace , Name : hra . Spec . ScaleTargetRef . Name } , & rd ) ; err != nil {
2022-02-16 02:08:56 -08:00
return groups , err
2021-12-19 01:29:44 -08:00
}
2022-02-16 02:08:56 -08:00
o , e , g = rd . Spec . Template . Spec . Organization , rd . Spec . Template . Spec . Enterprise , rd . Spec . Template . Spec . Group
default :
return nil , fmt . Errorf ( "unsupported scale target kind: %v" , kind )
}
2022-02-19 05:32:05 +00:00
if g != "" && e == "" && o == "" {
2022-02-16 02:08:56 -08:00
autoscaler . Log . V ( 1 ) . Info (
"invalid runner group config in scale target: spec.group must be set along with either spec.enterprise or spec.organization" ,
"scaleTargetKind" , kind ,
"group" , g ,
"enterprise" , e ,
"organization" , o ,
)
continue
}
if e != enterprise && o != org {
2022-02-19 05:32:05 +00:00
autoscaler . Log . V ( 1 ) . Info (
"Skipped scale target irrelevant to event" ,
"eventOrganization" , org ,
"eventEnterprise" , enterprise ,
"scaleTargetKind" , kind ,
"scaleTargetGroup" , g ,
"scaleTargetEnterprise" , e ,
"scaleTargetOrganization" , o ,
)
2022-02-16 02:08:56 -08:00
continue
}
rg := simulator . NewRunnerGroupFromProperties ( e , o , g )
if err := groups . Add ( rg ) ; err != nil {
return groups , fmt . Errorf ( "failed adding visible group from HRA %s/%s: %w" , hra . Namespace , hra . Name , err )
2021-12-19 01:29:44 -08:00
}
}
2022-02-16 02:08:56 -08:00
return groups , nil
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
}
func ( autoscaler * HorizontalRunnerAutoscalerGitHubWebhook ) getJobScaleTarget ( ctx context . Context , name string , labels [ ] string ) ( * ScaleTarget , error ) {
hras , err := autoscaler . findHRAsByKey ( ctx , name )
if err != nil {
return nil , err
}
autoscaler . Log . V ( 1 ) . Info ( fmt . Sprintf ( "Found %d HRAs by key" , len ( hras ) ) , "key" , name )
HRA :
for _ , hra := range hras {
if ! hra . ObjectMeta . DeletionTimestamp . IsZero ( ) {
continue
}
if len ( hra . Spec . ScaleUpTriggers ) > 1 {
autoscaler . Log . V ( 1 ) . Info ( "Skipping this HRA as it has too many ScaleUpTriggers to be used in workflow_job based scaling" , "hra" , hra . Name )
2022-04-24 13:37:26 +09:00
continue
}
if len ( hra . Spec . ScaleUpTriggers ) == 0 {
autoscaler . Log . V ( 1 ) . Info ( "Skipping this HRA as it has no ScaleUpTriggers configured" , "hra" , hra . Name )
continue
}
scaleUpTrigger := hra . Spec . ScaleUpTriggers [ 0 ]
if scaleUpTrigger . GitHubEvent == nil {
autoscaler . Log . V ( 1 ) . Info ( "Skipping this HRA as it has no `githubEvent` scale trigger configured" , "hra" , hra . Name )
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
continue
}
2022-04-24 13:37:26 +09:00
if scaleUpTrigger . GitHubEvent . WorkflowJob == nil {
autoscaler . Log . V ( 1 ) . Info ( "Skipping this HRA as it has no `githubEvent.workflowJob` scale trigger configured" , "hra" , hra . Name )
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
2022-04-24 13:37:26 +09:00
continue
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
}
2022-04-24 13:37:26 +09:00
duration := scaleUpTrigger . Duration
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
if duration . Duration <= 0 {
// Try to release the reserved capacity after at least 10 minutes by default,
// we won't end up in the reserved capacity remained forever in case GitHub somehow stopped sending us "completed" workflow_job events.
// GitHub usually send us those but nothing is 100% guaranteed, e.g. in case of something went wrong on GitHub :)
// Probably we'd better make this configurable via custom resources in the future?
duration . Duration = 10 * time . Minute
}
switch hra . Spec . ScaleTargetRef . Kind {
case "RunnerSet" :
var rs v1alpha1 . RunnerSet
if err := autoscaler . Client . Get ( context . Background ( ) , types . NamespacedName { Namespace : hra . Namespace , Name : hra . Spec . ScaleTargetRef . Name } , & rs ) ; err != nil {
return nil , err
}
// Ensure that the RunnerSet-managed runners have all the labels requested by the workflow_job.
for _ , l := range labels {
var matched bool
2021-12-19 02:55:23 +01:00
// ignore "self-hosted" label as all instance here are self-hosted
if l == "self-hosted" {
continue
}
2022-01-07 08:50:26 +09:00
// TODO labels related to OS and architecture needs to be explicitly declared or the current implementation will not be able to find them.
2021-12-19 02:55:23 +01:00
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
for _ , l2 := range rs . Spec . Labels {
if l == l2 {
matched = true
break
}
}
if ! matched {
continue HRA
}
}
return & ScaleTarget { HorizontalRunnerAutoscaler : hra , ScaleUpTrigger : v1alpha1 . ScaleUpTrigger { Duration : duration } } , nil
case "RunnerDeployment" , "" :
var rd v1alpha1 . RunnerDeployment
if err := autoscaler . Client . Get ( context . Background ( ) , types . NamespacedName { Namespace : hra . Namespace , Name : hra . Spec . ScaleTargetRef . Name } , & rd ) ; err != nil {
return nil , err
}
// Ensure that the RunnerDeployment-managed runners have all the labels requested by the workflow_job.
for _ , l := range labels {
var matched bool
2021-12-19 02:55:23 +01:00
// ignore "self-hosted" label as all instance here are self-hosted
if l == "self-hosted" {
continue
}
2022-01-07 08:50:26 +09:00
// TODO labels related to OS and architecture needs to be explicitly declared or the current implementation will not be able to find them.
2021-12-19 02:55:23 +01:00
2021-09-29 19:02:59 -07:00
for _ , l2 := range rd . Spec . Template . Spec . Labels {
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
if l == l2 {
matched = true
break
}
}
if ! matched {
continue HRA
}
}
return & ScaleTarget { HorizontalRunnerAutoscaler : hra , ScaleUpTrigger : v1alpha1 . ScaleUpTrigger { Duration : duration } } , nil
default :
return nil , fmt . Errorf ( "unsupported scaleTargetRef.kind: %v" , hra . Spec . ScaleTargetRef . Kind )
}
}
return nil , nil
}
2021-02-25 11:08:00 +09:00
func getValidCapacityReservations ( autoscaler * v1alpha1 . HorizontalRunnerAutoscaler ) [ ] v1alpha1 . CapacityReservation {
var capacityReservations [ ] v1alpha1 . CapacityReservation
now := time . Now ( )
for _ , reservation := range autoscaler . Spec . CapacityReservations {
if reservation . ExpirationTime . Time . After ( now ) {
capacityReservations = append ( capacityReservations , reservation )
}
}
return capacityReservations
}
2021-02-07 17:37:27 +09:00
func ( autoscaler * HorizontalRunnerAutoscalerGitHubWebhook ) SetupWithManager ( mgr ctrl . Manager ) error {
2021-02-16 18:51:33 +09:00
name := "webhookbasedautoscaler"
2021-02-19 10:33:04 +09:00
if autoscaler . Name != "" {
name = autoscaler . Name
}
2021-02-16 18:51:33 +09:00
autoscaler . Recorder = mgr . GetEventRecorderFor ( name )
2021-02-07 17:37:27 +09:00
2021-06-22 17:10:09 +09:00
if err := mgr . GetFieldIndexer ( ) . IndexField ( context . TODO ( ) , & v1alpha1 . HorizontalRunnerAutoscaler { } , scaleTargetKey , func ( rawObj client . Object ) [ ] string {
2021-02-07 17:37:27 +09:00
hra := rawObj . ( * v1alpha1 . HorizontalRunnerAutoscaler )
if hra . Spec . ScaleTargetRef . Name == "" {
2022-02-23 08:29:13 -08:00
autoscaler . Log . V ( 1 ) . Info ( fmt . Sprintf ( "scale target ref name not set for hra %s" , hra . Name ) )
2021-02-07 17:37:27 +09:00
return nil
}
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
switch hra . Spec . ScaleTargetRef . Kind {
case "" , "RunnerDeployment" :
var rd v1alpha1 . RunnerDeployment
if err := autoscaler . Client . Get ( context . Background ( ) , types . NamespacedName { Namespace : hra . Namespace , Name : hra . Spec . ScaleTargetRef . Name } , & rd ) ; err != nil {
2021-12-19 01:29:44 -08:00
autoscaler . Log . V ( 1 ) . Info ( fmt . Sprintf ( "RunnerDeployment not found with scale target ref name %s for hra %s" , hra . Spec . ScaleTargetRef . Name , hra . Name ) )
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
return nil
}
2021-12-19 01:29:44 -08:00
keys := [ ] string { }
if rd . Spec . Template . Spec . Repository != "" {
keys = append ( keys , rd . Spec . Template . Spec . Repository ) // Repository runners
}
if rd . Spec . Template . Spec . Organization != "" {
if group := rd . Spec . Template . Spec . Group ; group != "" {
keys = append ( keys , organizationalRunnerGroupKey ( rd . Spec . Template . Spec . Organization , rd . Spec . Template . Spec . Group ) ) // Organization runner groups
} else {
keys = append ( keys , rd . Spec . Template . Spec . Organization ) // Organization runners
}
}
2021-11-09 09:04:19 +09:00
if enterprise := rd . Spec . Template . Spec . Enterprise ; enterprise != "" {
2021-12-19 01:29:44 -08:00
if group := rd . Spec . Template . Spec . Group ; group != "" {
keys = append ( keys , enterpriseRunnerGroupKey ( enterprise , rd . Spec . Template . Spec . Group ) ) // Enterprise runner groups
} else {
keys = append ( keys , enterpriseKey ( enterprise ) ) // Enterprise runners
}
2021-11-09 09:04:19 +09:00
}
2022-02-17 09:15:26 +09:00
autoscaler . Log . V ( 2 ) . Info ( fmt . Sprintf ( "HRA keys indexed for HRA %s: %v" , hra . Name , keys ) )
2021-11-09 09:04:19 +09:00
return keys
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
case "RunnerSet" :
var rs v1alpha1 . RunnerSet
if err := autoscaler . Client . Get ( context . Background ( ) , types . NamespacedName { Namespace : hra . Namespace , Name : hra . Spec . ScaleTargetRef . Name } , & rs ) ; err != nil {
2021-12-19 01:29:44 -08:00
autoscaler . Log . V ( 1 ) . Info ( fmt . Sprintf ( "RunnerSet not found with scale target ref name %s for hra %s" , hra . Spec . ScaleTargetRef . Name , hra . Name ) )
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
return nil
}
2021-12-19 01:29:44 -08:00
keys := [ ] string { }
if rs . Spec . Repository != "" {
keys = append ( keys , rs . Spec . Repository ) // Repository runners
}
if rs . Spec . Organization != "" {
keys = append ( keys , rs . Spec . Organization ) // Organization runners
if group := rs . Spec . Group ; group != "" {
keys = append ( keys , organizationalRunnerGroupKey ( rs . Spec . Organization , rs . Spec . Group ) ) // Organization runner groups
}
}
2021-11-09 09:04:19 +09:00
if enterprise := rs . Spec . Enterprise ; enterprise != "" {
2021-12-19 01:29:44 -08:00
keys = append ( keys , enterpriseKey ( enterprise ) ) // Enterprise runners
if group := rs . Spec . Group ; group != "" {
keys = append ( keys , enterpriseRunnerGroupKey ( enterprise , rs . Spec . Group ) ) // Enterprise runner groups
}
2021-11-09 09:04:19 +09:00
}
2022-02-17 09:15:26 +09:00
autoscaler . Log . V ( 2 ) . Info ( fmt . Sprintf ( "HRA keys indexed for HRA %s: %v" , hra . Name , keys ) )
2021-11-09 09:04:19 +09:00
return keys
2021-02-07 17:37:27 +09:00
}
feat: Workflow job based ephemeral runner scaling (#721)
This add support for two upcoming enhancements on the GitHub side of self-hosted runners, ephemeral runners, and `workflow_jow` events. You can't use these yet.
**These features are not yet generally available to all GitHub users**. Please take this pull request as a preparation to make it available to actions-runner-controller users as soon as possible after GitHub released the necessary features on their end.
**Ephemeral runners**:
The former, ephemeral runners, is basically the reliable alternative to `--once`, which we've been using when you enabled `ephemeral: true` (default in actions-runner-controller).
`--once` has been suffering from a race issue #466. `--ephemeral` fixes that.
To enable ephemeral runners with `actions/runner`, you give `--ephemeral` to `config.sh`. This updated version of `actions-runner-controller` does it for you, by using `--ephemeral` instead of `--once` when you set `RUNNER_FEATURE_FLAG_EPHEMERAL=true`.
Please read the section `Ephemeral Runners` in the updated version of our README for more information.
Note that ephemeral runners is not released on GitHub yet. And `RUNNER_FEATURE_FLAG_EPHEMERAL=true` won't work at all until the feature gets released on GitHub. Stay tuned for an announcement from GitHub!
**`workflow_job` events**:
`workflow_job` is the additional webhook event that corresponds to each GitHub Actions workflow job run. It provides `actions-runner-controller` a solid foundation to improve our webhook-based autoscale.
Formerly, we've been exploiting webhook events like `check_run` for autoscaling. However, as none of our supported events has included `labels`, you had to configure an HRA to only match relevant `check_run` events. It wasn't trivial.
In contrast, a `workflow_job` event payload contains `labels` of runners requested. `actions-runner-controller` is able to automatically decide which HRA to scale by filtering the corresponding RunnerDeployment by `labels` included in the webhook payload. So all you need to use webhook-based autoscale will be to enable `workflow_job` on GitHub and expose actions-runner-controller's webhook server to the internet.
Note that the current implementation of `workflow_job` support works in two ways, increment, and decrement. An increment happens when the webhook server receives` workflow_job` of `queued` status. A decrement happens when it receives `workflow_job` of `completed` status. The latter is used to make scaling-down faster so that you waste money less than before. You still don't suffer from flapping, as a scale-down is still subject to `scaleDownDelaySecondsAfterScaleOut `.
Please read the section `Example 3: Scale on each `workflow_job` event` in the updated version of our README for more information on its usage.
2021-08-11 09:52:04 +09:00
return nil
2021-02-07 17:37:27 +09:00
} ) ; err != nil {
return err
}
return ctrl . NewControllerManagedBy ( mgr ) .
For ( & v1alpha1 . HorizontalRunnerAutoscaler { } ) .
2021-02-16 18:51:33 +09:00
Named ( name ) .
2021-02-07 17:37:27 +09:00
Complete ( autoscaler )
}
2021-11-09 09:04:19 +09:00
func enterpriseKey ( name string ) string {
return keyPrefixEnterprise + name
}
2021-12-19 01:29:44 -08:00
func organizationalRunnerGroupKey ( owner , group string ) string {
return owner + keyRunnerGroup + group
}
func enterpriseRunnerGroupKey ( enterprise , group string ) string {
return keyPrefixEnterprise + enterprise + keyRunnerGroup + group
}