# actions-runner-controller v0.23.0

All changes in this release can be found in the milestone https://github.com/actions/actions-runner-controller/milestone/3

This log documents breaking and major enhancements
## BREAKING CHANGE : Workflow job webhooks require an explicit field set

Previously the webhook event workflow job was set as the default if no `githubEvent` was set.

**Migration Steps**

Change this:

```yaml
  scaleUpTriggers:
  - githubEvent: {}
    duration: "30m"
```

To this:

```yaml
  scaleUpTriggers:
  - githubEvent:
      workflowJob: {}
    duration: "30m"
```

## BREAKING CHANGE : topologySpreadConstraints renamed to topologySpreadConstraint

Previously to use the pod `topologySpreadConstraint:` attribute in your runners you had to set `topologySpreadConstraints:` instead, this was a typo and has been corrected.

**Migration Steps**

Update your runners to use `topologySpreadConstraints:` instead

## BREAKING CHANGE : Default sync period is now 1 minute instead of 10 minutes

Since caching as been implemented the default sync period of 10 minutes is unnecessarily conservative and gives a poor out of the box user experience. If you need a 10 minute sync period ensure you explicitly set this value.

**Migration Steps**

Update your sync period, how this is done will depend on how you've deployed ARC.

## BREAKING CHANGE : A metric is set by default

Previously if no metric was provided and you were using pull based scaling the `TotalNumberOfQueuedAndInProgressWorkflowRuns` was metric applied. No default is set now.

**Migration Steps**

Add in the `TotalNumberOfQueuedAndInProgressWorkflowRuns` metric where you are currenty relying on it

```yaml

apiVersion: actions.summerwind.dev/v1alpha1
kind: RunnerDeployment
metadata:
  name: example-runner-deployment
spec:
  template:
    spec:
      organisation: my-awesome-organisation
      labels:
        - my-awesome-runner
---
apiVersion: actions.summerwind.dev/v1alpha1
kind: HorizontalRunnerAutoscaler
metadata:
  name: example-runner-deployment-autoscaler
spec:
  scaleTargetRef:
    name: example-runner-deployment
  minReplicas: 1
  maxReplicas: 5
  metrics:
  - type: TotalNumberOfQueuedAndInProgressWorkflowRuns
    repositoryNames:
    - owner/my-awesome-repo-1
    - owner/my-awesome-repo-2
    - owner/my-awesome-repo-3
```

## ENHANCEMENT : Find runner groups that visible to repository using a single API call

GitHub has contributed code to utilise a new API to enable us to get a repositories runner groups with a single API call. This enables us to scale runners based on the requesting repositories runner group membership without a series of expensive API queries.

This is an opt-in feature currently as it's a significant change in behaviour if enabled, additionally, whilst scaling based on the repositories runner group membership is supported in both GHES and github.com, only github.com currently has access to the new raate-limit budget friendly API.

To enable this set deploy via Helm and set `githubWebhookServer.useRunnerGroupsVisibility` to `true`.