-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
99 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,99 @@ | ||
| # actions-runner-controller v0.26.0 | ||
|
|
||
| All planned changes in this release can be found in the milestone https://github.com/actions-runner-controller/actions-runner-controller/milestone/9. | ||
|
|
||
| Also see https://github.com/actions-runner-controller/actions-runner-controller/compare/v0.24.2...v0.26.0 for full changelog. | ||
|
|
||
| This log documents breaking changes and major enhancements | ||
|
|
||
| ## Upgrading | ||
|
|
||
| In case you're using our Helm chart to deploy ARC, use the chart 0.21.0 or greater. Don't miss upgrading CRDs as usual! Helm doesn't upgrade CRDs. | ||
|
|
||
| ## BREAKING CHANGE : Min GHES version is now 3.6 | ||
|
|
||
| We've bumped the minimum requirement on GHES to [3.6.0](https://docs.github.com/en/[email protected]/admin/release-notes#3.6.0) which has been released in August. The motivator for us was to use the new `visible_to_repository` option added to the list runner groups API for the runner group visibility based autoscaling which is crucial when you have a lot of runner groups that have non-distinct set of labels. If you don't use runner groups at all, ARC may just work, but YMMV. | ||
|
|
||
| Relevant PR(s): #158 | ||
|
|
||
| ## ENHANCEMENT : Rootless DinD runners | ||
|
|
||
| An awesome GitHub staff added the support for rootless DinD powered runners. Compared to the standard DinD, a rootless DinD gives you an additional layer of security without losing the ability to invoke Docker containers and dokcer builds from within your workflow jobs. [If you aren't using the Kubernetes container mode](https://github.com/actions-runner-controller/actions-runner-controller#runner-with-k8s-jobs), you should be using this new rootless DinD. | ||
|
|
||
| Rootless DinD is the recent enhancement to Docker that basically allows you to run the Docker daemon and therefore Docker containers without the reliance on the `root` user. In the context of DinD(Docker-in-Docker) and ARC, this rootless DinD runner still requires a privileged container to function at all. But, the Linux user that runs the Docker daemon and the `actions/runner` agent can now be non-root, which is considered more secure than running DinD within a privileged container, as a random worfklow job is no longer able to run privileged operations. | ||
|
|
||
| Before using this feature, we highly recommend you to read [the detailed explanation in the original pull request](https://github.com/actions-runner-controller/actions-runner-controller/pull/1644) and [the new section in ARC's documentation](https://github.com/actions-runner-controller/actions-runner-controller#runner-with-rootless-dind). | ||
|
|
||
| Big kudos to @some-natalie for implementing and contributing this feature! | ||
|
|
||
| Relevant PR(s): #1644 | ||
|
|
||
| ## ENHANCEMENT : More granular and real-time runner statuses | ||
|
|
||
| We added another controller flag and a Helm chart value to enable the new runner status update hook. Once enabled, it exposes more granular runner phases via the runner status. | ||
|
|
||
| Previously, every `Runner` resource managed by `RunnerDeployment` was only able to expose these three Phases to e.g. `kubectl get runner` output: | ||
|
|
||
| - `Pending`- The runner pod is waiting to be scheduled on any Kubernetes node/ | ||
| - `Running`- The runner pod has been scheduled onto a node and its Linux namespace, containers, and the network has been set up. The primary processes of the containers are running. | ||
| - `Succeeded`- The primary processes of the pod containers have stopped with exit status 0. | ||
|
|
||
| As you may have realized, it had been quite useless, as it was a direct copy of the pod phase and tells almost nothing about the runner agent running inside the runner pod and the worfklow job that might be running. | ||
|
|
||
| Since #1268 though, it can optionally provide two more phases, and the modified version of the `Running` phase. Once enabled via the controller command-line flag or the Helm chart value, you start to see: | ||
|
|
||
| - `Registering`- The runner entrypoint started the runner registration process. Once the registration succeeds, it will update the phase to `Idle`. | ||
| - `Idle`- The runner has been registered to GitHub and it's still waiting for GitHub to assign a workflow job to run. | ||
| - `Running`- GitHub assigned a workflow job and the runner agent started running it. | ||
|
|
||
| All the three phases should be more useful than before. For example, `Registering` can tell you that it's (still) unable to register itself against the GitHub Actions service. It it's hanging for minutes at the `Registering` phase, it's very likely you misconfigured your GitHub API credentials or you've somehow broken runner pods so that the runner is unable to register itself. If it's stuck in `Idle` like forever even though you queued some workflow runs and jobs, it's very likely you misconfigured runner labels or the `on` field of your workflow definitions. | ||
|
|
||
| Big kudos to @fgalind1 for implementing and contributing this feature! | ||
|
|
||
| Relevant PR(s): #1268 | ||
|
|
||
| ## ENHANCEMENT : More Autoscaling-related metrics | ||
|
|
||
| We added several more metrics related to the pull-based autoscaling so that you can scrape it via the [Prometheus exposition format](https://github.com/Showmax/prometheus-docs/blob/master/content/docs/instrumenting/exposition_formats.md), track and observe the changes on the graphing, dashboarding and alerting solution of your choice. | ||
|
|
||
| For `PercentageRunnersBusy` metric, we added: | ||
|
|
||
| - horizontalrunnerautoscaler_replicas_desired | ||
| - horizontalrunnerautoscaler_runners | ||
| - horizontalrunnerautoscaler_runners_registered | ||
| - horizontalrunnerautoscaler_runners_busy | ||
| - horizontalrunnerautoscaler_terminating_busy | ||
|
|
||
| For `TotalNumberOfQueuedAndInProgressWorkflowRuns` metric, we added: | ||
|
|
||
| - horizontalrunnerautoscaler_necessary_replicas | ||
| - horizontalrunnerautoscaler_workflow_runs_completed | ||
| - horizontalrunnerautoscaler_workflow_runs_in_progress | ||
| - horizontalrunnerautoscaler_workflow_runs_queued | ||
| - horizontalrunnerautoscaler_workflow_runs_unknown | ||
|
|
||
| Big kudos to @debugger24 for implementing and contributing this feature! | ||
|
|
||
| Relevant PR(s): #1720 | ||
|
|
||
| ## ENHANCEMENT : Improved Multi-tenancy | ||
|
|
||
| We had a long-living feature request about reducing the number of ARC instances one needs to maintain to provide self-hosted runners across multiple enterprises and organizations, and here it is. You can now manage as many enterprises and organizations with ARC. | ||
|
|
||
| Previously you had to set up and manage an ARC instance per enterprise or in many cases per organization, because ARC was able to handle only one set of GitHub API credentials(PAT or GitHub App). The new multitenancy supports breaks this limitation by introducing the new `githubAPICredentialsFrom` field to the runner spec. You create a Kubernetes secret containing a GitHub API credentials and specify the secret name in `githubAPICredentialsFrom`, so that ARC picks it up and use it at the reconcilation time. | ||
|
|
||
| We've written a detailed guide about this feature in the ["Multitenancy" section of the README](https://github.com/actions-runner-controller/actions-runner-controller#multitenancy). Please read it and give it a try! | ||
|
|
||
| Lastly, this feature was stabilized by many early testers from the community. Big thanks and kudos to everyone who participated in testing, especially @Jalmeida1994 and @bm1216 for not only finding bugs but also contributing fixes ([#1725](https://github.com/actions-runner-controller/actions-runner-controller/pull/1725) and [#1781](https://github.com/actions-runner-controller/actions-runner-controller/pull/1781)! | ||
|
|
||
| Relevant PR(s): #1268 | ||
|
|
||
| ## ENHANCEMENT : Print ARC version number on startup | ||
|
|
||
| Our build script now injects the version number of ARC into the executable, and prints it on startup so that you can see from logs that which version of ARC you're currently running. Previously when you are to file a bug report, you had to be extra sure to know which version of ARC you're using and encountering an issue. It's now easier than ever because you can grab the version number show in the logs, without consulting the container image tag of chart's appVersion. | ||
|
|
||
| In addition to the logs, ARC is enhanced to send a HTTP `User-Agent` header containing the version number for every GitHub Actions API call ARC makes. You don't usually rely on it but GitHub and GitHub Actions's backend service can rely on it to collect the metrics about which versions of ARC folks are using. | ||
|
|
||
| Big kudos to @ViktorLindgren95 for implementing and contributing this feature! | ||
|
|
||
| Relevant PR(s): #1659 |
795cf8bThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a friendly comment that line 5
https://github.com/actions-runner-controller/actions-runner-controller/compare/v0.24.2...v0.26.0might have a typo. I think the first version is supposed to bev0.25.2?