actions/actions-runner-controller
1
0
Fork 0
mirror of https://github.com/actions/actions-runner-controller.git synced 2025-12-11 12:06:57 +00:00
Code Issues Packages Projects Releases Wiki Activity

Changes to folder structure to allow multigroups and changed go mod name (#2105)

Browse Source 
* Changed folder structure to allow multi group registration

* included actions.github.com directory for resources and controllers

* updated go module to actions/actions-runner-controller

* publish arc packages under actions-runner-controller

* Update charts/actions-runner-controller/docs/UPGRADING.md

Co-authored-by: Yusuke Kuoka <ykuoka@gmail.com>
This commit is contained in:
Nikola Jokic
2022-12-28 01:38:34 +01:00
committed by GitHub
parent 086f9fd2d6
commit aa6dab5a9a
113 changed files with 226 additions and 226 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/Actions-Runner-Controller-Overview.md
View File

@@ -42,7 +42,7 @@ The helm command (in the QuickStart guide) installs the custom resources into th
```console
helm install -f custom-values.yaml --wait --namespace actions-runner-system \
--create-namespace actions-runner-controller \
actions-runner-controller/actions-runner-controller
actions/actions-runner-controller
```
### Runner deployment

74
docs/detailed-docs.md
View File

@@ -53,7 +53,7 @@ ToC:
## People
`actions-runner-controller` is an open-source project currently developed and maintained in collaboration with maintainers @mumoshu and @toast-gear, various [contributors](https://github.com/actions-runner-controller/actions-runner-controller/graphs/contributors), and the [awesome community](https://github.com/actions-runner-controller/actions-runner-controller/discussions), mostly in their spare time.
`actions-runner-controller` is an open-source project currently developed and maintained in collaboration with maintainers @mumoshu and @toast-gear, various [contributors](https://github.com/actions/actions-runner-controller/graphs/contributors), and the [awesome community](https://github.com/actions/actions-runner-controller/discussions), mostly in their spare time.
If you think the project is awesome and it's becoming a basis for your important business, consider [sponsoring us](https://github.com/sponsors/actions-runner-controller)!
@@ -82,7 +82,7 @@ The documentation is kept inline with master@HEAD, we do our best to highlight a
## Getting Started
To give ARC a try with just a handful of commands, Please refer to [Quick start guide](/README.md#getting-started).
For an overview of ARC, please refer to [ARC Overview](https://github.com/actions-runner-controller/actions-runner-controller/blob/master/docs/Actions-Runner-Controller-Overview.md)
For an overview of ARC, please refer to [ARC Overview](https://github.com/actions/actions-runner-controller/blob/master/docs/Actions-Runner-Controller-Overview.md)
For more information, please refer to detailed documentation below!
@@ -99,7 +99,7 @@ After installing cert-manager, install the custom resource definitions and actio
```shell
# REPLACE "v0.25.2" with the version you wish to deploy
kubectl create -f https://github.com/actions-runner-controller/actions-runner-controller/releases/download/v0.25.2/actions-runner-controller.yaml
kubectl create -f https://github.com/actions/actions-runner-controller/releases/download/v0.25.2/actions-runner-controller.yaml
```
**Helm Deployment:**
@@ -109,7 +109,7 @@ Configure your values.yaml, see the chart's [README](../charts/actions-runner-co
```shell
helm repo add actions-runner-controller https://actions-runner-controller.github.io/actions-runner-controller
helm upgrade --install --namespace actions-runner-system --create-namespace \
--wait actions-runner-controller actions-runner-controller/actions-runner-controller
--wait actions-runner-controller actions/actions-runner-controller
```
### GitHub Enterprise Support
@@ -173,11 +173,11 @@ At this point you have a choice of configuring a webhook, a webhook is needed if
If you want to create a GitHub App for your account, open the following link to the creation page, enter any unique name in the "GitHub App name" field, and hit the "Create GitHub App" button at the bottom of the page.
- [Create GitHub Apps on your account](https://github.com/settings/apps/new?url=http://github.com/actions-runner-controller/actions-runner-controller&webhook_active=false&public=false&administration=write&actions=read)
- [Create GitHub Apps on your account](https://github.com/settings/apps/new?url=http://github.com/actions/actions-runner-controller&webhook_active=false&public=false&administration=write&actions=read)
If you want to create a GitHub App for your organization, replace the `:org` part of the following URL with your organization name before opening it. Then enter any unique name in the "GitHub App name" field, and hit the "Create GitHub App" button at the bottom of the page to create a GitHub App.
- [Create GitHub Apps on your organization](https://github.com/organizations/:org/settings/apps/new?url=http://github.com/actions-runner-controller/actions-runner-controller&webhook_active=false&public=false&administration=write&organization_self_hosted_runners=write&actions=read&checks=read)
- [Create GitHub Apps on your organization](https://github.com/organizations/:org/settings/apps/new?url=http://github.com/actions/actions-runner-controller&webhook_active=false&public=false&administration=write&organization_self_hosted_runners=write&actions=read&checks=read)
You will see an *App ID* on the page of the GitHub App you created as follows, the value of this App ID will be used later.
@@ -259,7 +259,7 @@ Configure your values.yaml, see the chart's [README](../charts/actions-runner-co
### Deploying Multiple Controllers
> This feature requires controller version => [v0.18.0](https://github.com/actions-runner-controller/actions-runner-controller/releases/tag/v0.18.0)
> This feature requires controller version => [v0.18.0](https://github.com/actions/actions-runner-controller/releases/tag/v0.18.0)
**_Note: Be aware when using this feature that CRDs are cluster-wide and so you should upgrade all of your controllers (and your CRDs) at the same time if you are doing an upgrade. Do not mix and match CRD versions with different controller versions. Doing so risks out of control scaling._**
@@ -294,7 +294,7 @@ We go into details about the differences between the 2 later, initially lets loo
### Repository Runners
To launch a single self-hosted runner, you need to create a manifest file that includes a `RunnerDeployment` resource as follows. This example launches a self-hosted runner with name *example-runnerdeploy* for the *actions-runner-controller/actions-runner-controller* repository.
To launch a single self-hosted runner, you need to create a manifest file that includes a `RunnerDeployment` resource as follows. This example launches a self-hosted runner with name *example-runnerdeploy* for the *actions/actions-runner-controller* repository.
```yaml
# runnerdeployment.yaml
@@ -404,7 +404,7 @@ example-runnerdeploy2475ht2qbr mumoshu/actions-runner-controller-ci Running
### RunnerSets
> This feature requires controller version => [v0.20.0](https://github.com/actions-runner-controller/actions-runner-controller/releases/tag/v0.20.0)
> This feature requires controller version => [v0.20.0](https://github.com/actions/actions-runner-controller/releases/tag/v0.20.0)
We can also deploy sets of RunnerSets the same way, a basic `RunnerSet` would look like this:
@@ -473,7 +473,7 @@ spec:
# Usually, the runner container's privileged field is derived from dockerdWithinRunnerContainer.
# But in the case where you need to run privileged job steps even if you don't use docker/don't need dockerd within the runner container,
# just specified `privileged: true` like this.
# See https://github.com/actions-runner-controller/actions-runner-controller/issues/1282
# See https://github.com/actions/actions-runner-controller/issues/1282
# Do note that specifying `privileged: false` while using dind is very likely to fail, even if you use some vm-based container runtimes
# like firecracker and kata. Basically they run containers within dedicated micro vms and so
# it's more like you can use `privileged: true` safer with those runtimes.
@@ -489,7 +489,7 @@ spec:
memory: "4Gi"
```
You can also read the design and usage documentation written in the original pull request that introduced `RunnerSet` for more information [#629](https://github.com/actions-runner-controller/actions-runner-controller/pull/629).
You can also read the design and usage documentation written in the original pull request that introduced `RunnerSet` for more information [#629](https://github.com/actions/actions-runner-controller/pull/629).
Under the hood, `RunnerSet` relies on Kubernetes's `StatefulSet` and Mutating Webhook. A `statefulset` is used to create a number of pods that has stable names and dynamically provisioned persistent volumes, so that each `statefulset-managed` pod gets the same persistent volume even after restarting. A mutating webhook is used to dynamically inject a runner's "registration token" which is used to call GitHub's "Create Runner" API.
@@ -509,11 +509,11 @@ Persistent runners are available as an option for some edge cases however they a
### Autoscaling
> If you are using controller version < [v0.22.0](https://github.com/actions-runner-controller/actions-runner-controller/releases/tag/v0.22.0) and you are not using GHES, and so you can't set your rate limit budget, it is recommended that you use 100 replicas or fewer to prevent being rate limited.
> If you are using controller version < [v0.22.0](https://github.com/actions/actions-runner-controller/releases/tag/v0.22.0) and you are not using GHES, and so you can't set your rate limit budget, it is recommended that you use 100 replicas or fewer to prevent being rate limited.
A `RunnerDeployment` or `RunnerSet` can scale the number of runners between `minReplicas` and `maxReplicas` fields driven by either pull based scaling metrics or via a webhook event. Whether the autoscaling is driven from a webhook event or pull based metrics it is implemented by backing a `RunnerDeployment` or `RunnerSet` kind with a `HorizontalRunnerAutoscaler` kind.
**_Important!!! If you opt to configure autoscaling, ensure you remove the `replicas:` attribute in the `RunnerDeployment` / `RunnerSet` kinds that are configured for autoscaling [#206](https://github.com/actions-runner-controller/actions-runner-controller/issues/206#issuecomment-748601907)_**
**_Important!!! If you opt to configure autoscaling, ensure you remove the `replicas:` attribute in the `RunnerDeployment` / `RunnerSet` kinds that are configured for autoscaling [#206](https://github.com/actions/actions-runner-controller/issues/206#issuecomment-748601907)_**
#### Anti-Flapping Configuration
@@ -638,10 +638,10 @@ spec:
The `HorizontalRunnerAutoscaler` will poll GitHub for the number of runners in the `busy` state which live in the RunnerDeployment's namespace, it will then scale depending on how you have configured the scale factors.
**Benefits of this metric**
1. Supports named repositories server-side the same as the `TotalNumberOfQueuedAndInProgressWorkflowRuns` metric [#313](https://github.com/actions-runner-controller/actions-runner-controller/pull/313)
2. Supports GitHub organization wide scaling without maintaining an explicit list of repositories, this is especially useful for those that are working at a larger scale. [#223](https://github.com/actions-runner-controller/actions-runner-controller/pull/223)
1. Supports named repositories server-side the same as the `TotalNumberOfQueuedAndInProgressWorkflowRuns` metric [#313](https://github.com/actions/actions-runner-controller/pull/313)
2. Supports GitHub organization wide scaling without maintaining an explicit list of repositories, this is especially useful for those that are working at a larger scale. [#223](https://github.com/actions/actions-runner-controller/pull/223)
3. Like all scaling metrics, you can manage workflow allocation to the RunnerDeployment through the use of [GitHub labels](#runner-labels)
4. Supports scaling desired runner count on both a percentage increase / decrease basis as well as on a fixed increase / decrease count basis [#223](https://github.com/actions-runner-controller/actions-runner-controller/pull/223) [#315](https://github.com/actions-runner-controller/actions-runner-controller/pull/315)
4. Supports scaling desired runner count on both a percentage increase / decrease basis as well as on a fixed increase / decrease count basis [#223](https://github.com/actions/actions-runner-controller/pull/223) [#315](https://github.com/actions/actions-runner-controller/pull/315)
**Drawbacks of this metric**
1. May not scale quickly enough for some users' needs. This metric is pull based and so the number of busy runners is polled as configured by the sync period, as a result scaling performance is bound by this sync period meaning there is a lag to scaling activity.
@@ -695,7 +695,7 @@ spec:
#### Webhook Driven Scaling
> This feature requires controller version => [v0.20.0](https://github.com/actions-runner-controller/actions-runner-controller/releases/tag/v0.20.0)
> This feature requires controller version => [v0.20.0](https://github.com/actions/actions-runner-controller/releases/tag/v0.20.0)
> To configure pull driven scaling see the [Pull Driven Scaling](#pull-driven-scaling) section
@@ -769,7 +769,7 @@ _[see the values documentation for all configuration options](../charts/actions-
```console
$ helm upgrade --install --namespace actions-runner-system --create-namespace \
--wait actions-runner-controller actions-runner-controller/actions-runner-controller \
--wait actions-runner-controller actions/actions-runner-controller \
--set "githubWebhookServer.enabled=true,service.type=NodePort,githubWebhookServer.ports[0].nodePort=33080"
```
@@ -791,7 +791,7 @@ If you plan to expose ARC via Ingress, you might not be required to make it a `N
```console
$ helm upgrade --install --namespace actions-runner-system --create-namespace \
--wait actions-runner-controller actions-runner-controller/actions-runner-controller \
--wait actions-runner-controller actions/actions-runner-controller \
--set "githubWebhookServer.enabled=true"
```
@@ -881,9 +881,9 @@ kind: Kustomization
resources:
# You should already have this
- github.com/actions-runner-controller/actions-runner-controller/config//default?ref=v0.22.2
- github.com/actions/actions-runner-controller/config//default?ref=v0.22.2
# Add the below!
- github.com/actions-runner-controller/actions-runner-controller/config//github-webhook-server?ref=v0.22.2
- github.com/actions/actions-runner-controller/config//github-webhook-server?ref=v0.22.2
Finally, you will have to configure an ingress so that you may configure the webhook in github. An example of such ingress can be find below:
@@ -908,7 +908,7 @@ spec:
#### Autoscaling to/from 0
> This feature requires controller version => [v0.19.0](https://github.com/actions-runner-controller/actions-runner-controller/releases/tag/v0.19.0)
> This feature requires controller version => [v0.19.0](https://github.com/actions/actions-runner-controller/releases/tag/v0.19.0)
The regular `RunnerDeployment` / `RunnerSet` `replicas:` attribute as well as the `HorizontalRunnerAutoscaler` `minReplicas:` attribute supports being set to 0.
@@ -926,7 +926,7 @@ Webhook-based autoscaling is the best option as it is relatively easy to configu
#### Scheduled Overrides
> This feature requires controller version => [v0.19.0](https://github.com/actions-runner-controller/actions-runner-controller/releases/tag/v0.19.0)
> This feature requires controller version => [v0.19.0](https://github.com/actions/actions-runner-controller/releases/tag/v0.19.0)
`Scheduled Overrides` allows you to configure `HorizontalRunnerAutoscaler` so that its `spec:` gets updated only during a certain period of time. This feature is usually used for the following scenarios:
@@ -1189,7 +1189,7 @@ spec:
name: docker-extra
# You can mount some of the shared volumes to the runner container using volumeMounts.
# NOTE: Do not try to mount the volume onto the runner workdir itself as it will not work. You could mount it however on a subdirectory in the runner workdir
# Please see https://github.com/actions-runner-controller/actions-runner-controller/issues/630#issuecomment-862087323 for more information.
# Please see https://github.com/actions/actions-runner-controller/issues/630#issuecomment-862087323 for more information.
volumeMounts:
- mountPath: /home/runner/work/repo
name: repo
@@ -1203,7 +1203,7 @@ spec:
# The default limit is undefined.
# NOTE: You can make sure that nodes' resources are never exceeded by limiting used storage size per runner pod.
# You can even disable the runner mount completely by setting limit to zero if dockerdWithinRunnerContainer = true.
# Please see https://github.com/actions-runner-controller/actions-runner-controller/pull/674 for more information.
# Please see https://github.com/actions/actions-runner-controller/pull/674 for more information.
volumeSizeLimit: 4Gi
# Optional name of the container runtime configuration that should be used for pods.
# This must match the name of a RuntimeClass resource available on the cluster.
@@ -1215,7 +1215,7 @@ spec:
# Usually, the runner container's privileged field is derived from dockerdWithinRunnerContainer.
# But in the case where you need to run privileged job steps even if you don't use docker/don't need dockerd within the runner container,
# just specified `privileged: true` like this.
# See https://github.com/actions-runner-controller/actions-runner-controller/issues/1282
# See https://github.com/actions/actions-runner-controller/issues/1282
# Do note that specifying `privileged: false` while using dind is very likely to fail, even if you use some vm-based container runtimes
# like firecracker and kata. Basically they run containers within dedicated micro vms and so
# it's more like you can use `privileged: true` safer with those runtimes.
@@ -1375,7 +1375,7 @@ reused across runner pods to retain `/var/lib/docker`.
_Be sure to add the volume mount to the container that is supposed to run the docker daemon._
_Be sure to trigger several workflow runs before checking if the cache is effective. ARC requires an `Available` PV to be reused for the new runner pod, and a PV becomes `Available` only after some time after the previous runner pod that was using the PV terminated. See [the related discussion](https://github.com/actions-runner-controller/actions-runner-controller/discussions/1605)._
_Be sure to trigger several workflow runs before checking if the cache is effective. ARC requires an `Available` PV to be reused for the new runner pod, and a PV becomes `Available` only after some time after the previous runner pod that was using the PV terminated. See [the related discussion](https://github.com/actions/actions-runner-controller/discussions/1605)._
By default, ARC creates a sidecar container named `docker` within the runner pod for running the docker daemon. In that case,
it's where you need the volume mount so that the manifest looks like:
@@ -1412,7 +1412,7 @@ With `dockerdWithinRunnerContainer: true`, you need to add the volume mount to t
The module cache dir can be customized by setting `GOMOD_CACHE` so by setting it to somewhere under `$HOME/.cache`,
we can have a single PV to host both build and module cache, which might improve Go module downloading and building time.
_Be sure to trigger several workflow runs before checking if the cache is effective. ARC requires an `Available` PV to be reused for the new runner pod, and a PV becomes `Available` only after some time after the previous runner pod that was using the PV terminated. See [the related discussion](https://github.com/actions-runner-controller/actions-runner-controller/discussions/1605)._
_Be sure to trigger several workflow runs before checking if the cache is effective. ARC requires an `Available` PV to be reused for the new runner pod, and a PV becomes `Available` only after some time after the previous runner pod that was using the PV terminated. See [the related discussion](https://github.com/actions/actions-runner-controller/discussions/1605)._
```yaml
kind: RunnerSet
@@ -1508,7 +1508,7 @@ spec:
replicas: 1
template:
spec:
repository: actions-runner-controller/actions-runner-controller
repository: actions/actions-runner-controller
labels:
- custom-runner
```
@@ -1589,7 +1589,7 @@ spec:
# Specify the duration to wait for the docker daemon to be available
# The default duration of 120 seconds is sometimes too short
# to reliably wait for the docker daemon to start
# See https://github.com/actions-runner-controller/actions-runner-controller/issues/1804
# See https://github.com/actions/actions-runner-controller/issues/1804
- name: WAIT_FOR_DOCKER_SECONDS
value: 120
# Disables the wait for the docker daemon to be available check
@@ -1617,7 +1617,7 @@ spec:
image: summerwind/actions-runner-dind
env:
# Sets the respective default-address-pools fields within dockerd daemon.json
# See https://github.com/actions-runner-controller/actions-runner-controller/pull/1971 for more information.
# See https://github.com/actions/actions-runner-controller/pull/1971 for more information.
# Also see https://github.com/docker/docs/issues/8663 for the default base/size values in dockerd.
- name: DOCKER_DEFAULT_ADDRESS_POOL_BASE
value: "172.17.0.0/12"
@@ -1627,7 +1627,7 @@ spec:
### Using IRSA (IAM Roles for Service Accounts) in EKS
> This feature requires controller version => [v0.15.0](https://github.com/actions-runner-controller/actions-runner-controller/releases/tag/v0.15.0)
> This feature requires controller version => [v0.15.0](https://github.com/actions/actions-runner-controller/releases/tag/v0.15.0)
Similar to regular pods and deployments, you firstly need an existing service account with the IAM role associated.
Create one using e.g. `eksctl`. You can refer to [the EKS documentation](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) for more details.
@@ -1690,7 +1690,7 @@ kind: RunnerDeployment
metadata:
name: custom-runner
spec:
repository: actions-runner-controller/actions-runner-controller
repository: actions/actions-runner-controller
image: YOUR_CUSTOM_RUNNER_IMAGE
```
@@ -1722,7 +1722,7 @@ Set the Helm chart values as follows:
```shell
$ CA_BUNDLE=$(cat path/to/ca.pem | base64)
$ helm upgrade --install actions-runner-controller/actions-runner-controller \
$ helm upgrade --install actions/actions-runner-controller \
certManagerEnabled=false \
admissionWebHooks.caBundle=${CA_BUNDLE}
```
@@ -1732,7 +1732,7 @@ $ helm upgrade --install actions-runner-controller/actions-runner-controller \
Set the Helm chart values as follows:
```shell
$ helm upgrade --install actions-runner-controller/actions-runner-controller \
$ helm upgrade --install actions/actions-runner-controller \
certManagerEnabled=false
```
@@ -1790,7 +1790,7 @@ spec:
#### Dockerfile
> Note that you'd need to patch the below Dockerfile if you need a graceful termination.
> See https://github.com/actions-runner-controller/actions-runner-controller/pull/1608/files#r917319574 for more information.
> See https://github.com/actions/actions-runner-controller/pull/1608/files#r917319574 for more information.
```Dockerfile
FROM mcr.microsoft.com/windows/servercore:ltsc2019
@@ -1850,7 +1850,7 @@ After both `RunnerDeployment`'s are up and running, you can now proceed to deplo
### Multitenancy
> This feature requires controller version => [v0.26.0](https://github.com/actions-runner-controller/actions-runner-controller/releases/tag/v0.26.0)
> This feature requires controller version => [v0.26.0](https://github.com/actions/actions-runner-controller/releases/tag/v0.26.0)
In a large enterprise, there might be many GitHub organizations that requires self-hosted runners. Previously, the only way to provide ARC-managed self-hosted runners in such environment was [Deploying Multiple Controllers](#deploying-multiple-controllers), which incurs overhead due to it requires one ARC installation per GitHub organization.

6
docs/releasenotes/0.22.md
View File

@@ -23,7 +23,7 @@ In terms of reliability, the first thing to note is that it has a new scale down
Previously every runner pod can restart immediately after the completion, while at the same time ARC might mark the same runner pod for deletion due to scale down.
That resulted in various race conditions that terminated the runner prematurely while running a workflow job[^2].
[^2]: See [this issue](https://github.com/actions-runner-controller/actions-runner-controller/issues/911) for more context.
[^2]: See [this issue](https://github.com/actions/actions-runner-controller/issues/911) for more context.
And it's now fixed. The new scale down process ensures that the runner has been registered successfully and then de-registered from GitHub Actions, before starting the runner pod deletion process.
Any runner pod can't be terminated while being restarting or running a job now, which makes it impossible to be in the middle of running a workflow job when a runner pod is being terminated. No more race conditions.
@@ -34,9 +34,9 @@ It is also worth mentioning that the new scale down process makes less GitHub Ac
Two enhancements had been made on that.
First, every runner managed by ARC now [uses `--ephemeral` by default](https://github.com/actions-runner-controller/actions-runner-controller/pull/1211).
First, every runner managed by ARC now [uses `--ephemeral` by default](https://github.com/actions/actions-runner-controller/pull/1211).
Second, we [removed unnecessary `RemoveRunner` API calls](https://github.com/actions-runner-controller/actions-runner-controller/pull/1204) when it's an ephemeral runner that has already completed running.
Second, we [removed unnecessary `RemoveRunner` API calls](https://github.com/actions/actions-runner-controller/pull/1204) when it's an ephemeral runner that has already completed running.
[GitHub designed ephemeral runners to be automatically unregistered from GitHub Actions after running their first workflow jobs](https://github.blog/changelog/2021-09-20-github-actions-ephemeral-self-hosted-runners-new-webhooks-for-auto-scaling). It is unnecessary to call `RemoveRunner` API when the ephemeral runner pod has already completed successfully. These two enhancements aligns with that fact and it results in ARC making less API calls.

2
docs/releasenotes/0.23.md
View File

@@ -1,6 +1,6 @@
# actions-runner-controller v0.23.0
All changes in this release can be found in the milestone https://github.com/actions-runner-controller/actions-runner-controller/milestone/3
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

6
docs/releasenotes/0.24.md
View File

@@ -1,6 +1,6 @@
# actions-runner-controller v0.24.0
All changes in this release can be found in the milestone https://github.com/actions-runner-controller/actions-runner-controller/milestone/4
All changes in this release can be found in the milestone https://github.com/actions/actions-runner-controller/milestone/4
This log documents breaking and major enhancements
@@ -32,7 +32,7 @@ Relevant PR(s): #1395, #1420
This is a frequently asked feature that alows you to force `privileged: true` in case you don't need docker but still need privileged tasks to be run in a job step.
In combination with a container runtime like `sysbox` this should enable you to run docker builds within the dind sidecar, all without privileges. See [the discussion related to Sysbox](https://github.com/actions-runner-controller/actions-runner-controller/discussions/977) for more information.
In combination with a container runtime like `sysbox` this should enable you to run docker builds within the dind sidecar, all without privileges. See [the discussion related to Sysbox](https://github.com/actions/actions-runner-controller/discussions/977) for more information.
Note that we ARC maintainers still have no bandwidth to provide a complete description on how to make ARC work with `sysbox` yet, but almost certainly we'd welcome contributions to the documentation if you managed to make it work.
@@ -42,7 +42,7 @@ Relevant PR(s): #1383
This enhancement makes it more practical to use RunnerSet in combination with `volumeClaimTemplates` to make your workflow jobs faster.
Please see our updated ["Custom Volume Mounts" section in the documentation](https://github.com/actions-runner-controller/actions-runner-controller#custom-volume-mounts) for more information. Currently, we cover caching Docker image layers, go mod/build, and PV-backed runner work directory(Although this one is backed by another feature unrelated to this enhancement under the hood).
Please see our updated ["Custom Volume Mounts" section in the documentation](https://github.com/actions/actions-runner-controller#custom-volume-mounts) for more information. Currently, we cover caching Docker image layers, go mod/build, and PV-backed runner work directory(Although this one is backed by another feature unrelated to this enhancement under the hood).
Relevant PR(s): #1340

8
docs/releasenotes/0.25.md
View File

@@ -1,8 +1,8 @@
# actions-runner-controller v0.25.0
All planned changes in this release can be found in the milestone https://github.com/actions-runner-controller/actions-runner-controller/milestone/8.
All planned changes in this release can be found in the milestone https://github.com/actions/actions-runner-controller/milestone/8.
Also see https://github.com/actions-runner-controller/actions-runner-controller/compare/v0.24.1...v0.25.0 for full changelog.
Also see https://github.com/actions/actions-runner-controller/compare/v0.24.1...v0.25.0 for full changelog.
This log documents breaking changes and major enhancements
@@ -12,7 +12,7 @@ In case you're using our Helm chart to deploy ARC, use the chart 0.20.0 or great
## BREAKING CHANGE : Support for `--once` has been dropped
In case you're still on ARC v0.23.0 or earlier, please also read [the relevant part of v0.24.0 release note for more information](https://github.com/actions-runner-controller/actions-runner-controller/blob/master/docs/releasenotes/0.24.md#breaking-change--support-for---once-is-being-dropped).
In case you're still on ARC v0.23.0 or earlier, please also read [the relevant part of v0.24.0 release note for more information](https://github.com/actions/actions-runner-controller/blob/master/docs/releasenotes/0.24.md#breaking-change--support-for---once-is-being-dropped).
Relevant PR(s): #1580, #1590
@@ -22,7 +22,7 @@ The GitHub Actions team has recently added `actions/runner` an ability to use [r
To use the new container mode, you set `.spec.template.spec.containerMode` in `RunnerDeployment` to `"kubernetes"`, while defining `.spec.template.spec.workVolumeClaimTemplate`. The volume claim template is used for provisioning and assigning persistent volumes mounted across the runner pod and the job pods for sharing the job workspace.
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/1546), and [the new section in ARC's documentation](https://github.com/actions-runner-controller/actions-runner-controller#runner-with-k8s-jobs).
Before using this feature, we highly recommend you to read [the detailed explanation in the original pull request](https://github.com/actions/actions-runner-controller/pull/1546), and [the new section in ARC's documentation](https://github.com/actions/actions-runner-controller#runner-with-k8s-jobs).
Big kudos to @thboop and the GitHub Actions team for implementing and contributing this feature!

12
docs/releasenotes/0.26.md
View File

@@ -1,8 +1,8 @@
# 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.
All planned changes in this release can be found in the milestone https://github.com/actions/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.
Also see https://github.com/actions/actions-runner-controller/compare/v0.24.2...v0.26.0 for full changelog.
This log documents breaking changes and major enhancements
@@ -18,11 +18,11 @@ 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.
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/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).
Before using this feature, we highly recommend you to read [the detailed explanation in the original pull request](https://github.com/actions/actions-runner-controller/pull/1644) and [the new section in ARC's documentation](https://github.com/actions/actions-runner-controller#runner-with-rootless-dind).
Big kudos to @some-natalie for implementing and contributing this feature!
@@ -82,9 +82,9 @@ We had a long-living feature request about reducing the number of ARC instances
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!
We've written a detailed guide about this feature in the ["Multitenancy" section of the README](https://github.com/actions/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)!
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/actions-runner-controller/pull/1725) and [#1781](https://github.com/actions/actions-runner-controller/pull/1781)!
Relevant PR(s): #1268