Skip to content

Latest commit

 

History

History
89 lines (63 loc) · 3 KB

0.23.md

File metadata and controls

89 lines (63 loc) · 3 KB
Raw

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:

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

To this:

  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

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.