Repository files navigation

• Run ARC on Openshift without defeating the Openshift security
• Be able to build container images in Actions workflows run by ARC runners
  • Kaniko will be used since it does not require root privilege on the cluster nodes

• Createdtwo Dockerfile for the ARC runners on OCP;
  • one with root access throughsudo (Dockerfile):
    • the image is based onthe default runner image and includes all the kaniko tooling;
    • image ispublicly available
    • pros: developpers will be able to runsudo commands (e.g.sudo apt install) directly in their Actions workflows if needed;
    • cons: will requireanyuid SCC (see How to below) which is not a good practice in an Openshift environment (defeats the Openshift security);
  • one fully rootless (Dockerfile):
    • the image is based onthe official doc to build custom ARC runner image and includes all the kaniko tooling;
    • image ispublicly available
    • pros: fully supportsarbitrary user ids from Openshift (best security practice);
    • cons: the packages required to run the workflows must be installed inthe Dockerfile;
• Created 2 Helm values file for the runner set on Openshift
  • the only difference is actually the image used by the runner
    • onevalues file for the root-enabled image;
    • onevalues file for the rootless image;
• Createda test repository with:
  • kaniko-* actions for login to private registry and build/push image;
  • a sample workflow to test the whole setup by building a simple container image and pushing it to GHCR.

• Improve thekaniko-build-push action to handle more cases

1. Download CRC fromRed Hat website
2. crc setup
   • you'll need the pull secret that you can retrieve from the Red Hat portal
3. crc start
4. Once the cluster has started, runcrc console --credentials to retrieve the command line to authenticate as cluster admin
5. oc login -u kubeadmin -p hR5Dp.....dYIrS-zDu6V https://api.crc.testing:6443

There is nothing to modify compared to the defaultARC controller install on K8S:

NAMESPACE="arc-systems"helm install arc \    --namespace "${NAMESPACE}" \    --create-namespace \    oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set-controller

We use theGitHub app auth method to authenticate ARC runners to GitHub.

# Once you installed your own app on the org with the above doc:$ APP_ID=813936$ INSTALL_ID=46842723$ GPG_KEY=./gpg.key # the gpg key file is retrieved from GitHub.com and stored locally$ oc new-project arc-runners$ oc create secret generic pre-defined-secret \   --namespace=arc-runners \   --from-literal=github_app_id=$APP_ID \   --from-literal=github_app_installation_id=$INSTALL_ID \   --from-file=github_app_private_key=$GPG_KEY# Verify the secret$ oc extract --to=- secret/pre-defined-secret

$cd actions-runner-controller/$ INSTALLATION_NAME="arc-runner-set-ocp"NAMESPACE="arc-runners"helm upgrade --install"${INSTALLATION_NAME}" \    --namespace"${NAMESPACE}" \    --values ./charts/gha-runner-scale-set/values-openshift.yaml \    --set githubConfigUrl="https://github.com/arc-on-ocp" \    --set githubConfigSecret="pre-defined-secret" \    --set minRunners=1 \    ./charts/gha-runner-scale-set# Allow the runners to use sudo and anyuid# By default, the runner process runs with UID 1001 but it can do sudo for certain tasks$ oc adm policy add-scc-to-user anyuid -z arc-runner-set-ocp-gha-rs-no-permission -n arc-runners

$cd actions-runner-controller/$ INSTALLATION_NAME="arc-runner-set-ocp"NAMESPACE="arc-runners"helm upgrade --install"${INSTALLATION_NAME}" \    --namespace"${NAMESPACE}" \    --values ./charts/gha-runner-scale-set/values-openshift-rootless.yaml \    --set githubConfigUrl="https://github.com/arc-on-ocp" \    --set githubConfigSecret="pre-defined-secret" \    --set minRunners=1 \    ./charts/gha-runner-scale-set

Go tothe Actions tab of the test repository (where the kaniko actions and test workflow resides) and trigger manually the test workflow.

Actions Runner Controller (ARC) is a Kubernetes operator that orchestrates and scales self-hosted runners for GitHub Actions.

With ARC, you can create runner scale sets that automatically scale based on the number of workflows running in your repository, organization, or enterprise. Because controlled runners can be ephemeral and based on containers, new runner instances can scale up or down rapidly and cleanly. For more information about autoscaling, see"Autoscaling with self-hosted runners."

You can set up ARC on Kubernetes using Helm, then create and run a workflow that uses runner scale sets. For more information about runner scale sets, see"Deploying runner scale sets with Actions Runner Controller."

Actions Runner Controller (ARC) is an open-source project currently developed and maintained in collaboration with the GitHub Actions team, external maintainers @mumoshu and @toast-gear, variouscontributors, and theawesome community.

If you think the project is awesome and is adding value to your business, please consider directly sponsoringcommunity maintainers and individual contributors via GitHub Sponsors.

In case you are already the employer of one of contributors, sponsoring via GitHub Sponsors might not be an option. Just support them in other means!

Seethe sponsorship dashboard for the former and the current sponsors.

To give ARC a try with just a handful of commands, Please refer to theQuickstart guide.

For an overview of ARC, please refer toAbout ARC

With the introduction ofautoscaling runner scale sets, the existingautoscaling modes are now legacy. The legacy modes have certain use cases and will continue to be maintained by the community only.

For further information on what is supported by GitHub and what's managed by the community, please refer tothis announcement discussion.

ARC documentation is available ondocs.github.com.

The following documentation is for the legacy autoscaling modes that continue to be maintained by the community

• Quickstart guide
• About ARC
• Installing ARC
• Authenticating to the GitHub API
• Deploying ARC runners
• Adding ARC runners to a repository, organization, or enterprise
• Automatically scaling runners
• Using custom volumes
• Using ARC runners in a workflow
• Managing access with runner groups
• Configuring Windows runners
• Using ARC across organizations
• Using entrypoint features
• Deploying alternative runners
• Monitoring and troubleshooting

We welcome contributions from the community. For more details on contributing to the project (including requirements), please refer to "Getting Started with Contributing."

We are very happy to help you with any issues you have. Please refer to the "Troubleshooting" section for common issues.