Skip to content

Latest commit

 

History

History

images

README.md

Docker stuff for the runners

Quick Facts

❓ Looking to add software to the runners? If the package version that is currently in the default repositories for that OS is acceptable, add it to the appropriate Dockerfile. If a newer version is needed or it isn't in the repositories, add a Bash script in the software folder and call that from the Dockerfile.

ℹ️ In general, we're fine with adding software that's generally useful to people so long as it doesn't break existing things. If you require a bespoke environment with specific dependency management, you should use your own compute. You can find the directions for that here.

⚠️ These are ephemeral pods! Don't rely on the output being available between workflow steps, runs, etc. GitHub Actions is also designed to be parallel by default, so try to use that to your advantage when you can.

What this folder is all about

Here's a quick breakdown of the folder structure here:

  • docker - Contains the config files needed for the Docker daemon that runs inside each pod. The pods are all capable of Docker-in-Docker, as quite a few Actions ship as Docker images.
  • patched - Has all the files around the Actions Runner software to run as a service.
  • software - Bash scripts that install software on the pods at build time.
  • supervisor - The Debian-based runners use supervisord to launch/control Docker within the pod.

In addition to the folders above, here's a bit about the files in this folder.

  • The Dockerfiles are ... exactly what you think they are really.

  • entrypoint.sh - The entry point script launches the runner, connects to GitHub, and joins the enterprise pool.

  • logger.sh - A handy dandy logger script!

  • modprobe - Not really modprobe, but kinda needed to let Docker-in-Docker run more reliably.

  • startup.sh - The startup script. It's a bit ugly, but it works. It relies on supervisord for the Debian-based runners, but if it fails (such as CentOS), it'll try sudo $process before failing for good.

  • .env - This file gets copied into the container during the build process, then loaded by the entry point script. Use this to store custom environment variables, such as proxy configurations, caching, mirrors, etc. that you need in your on-premises environment. It is blank by default as this is a public repository, but here's an example:

    HTTP_PROXY=http://USERNAME:PASSWORD@10.0.1.1:8080/
HTTPS_PROXY=https://USERNAME:PASSWORD@10.0.0.1:8080/