feat(arc): add a node-cache capability that shares a node directory between a profile's pods

README.md

@@ -47,7 +47,7 @@ An Unraid host runs the same cluster role as any other Docker host (it ships Doc
 
 ### Capabilities
 
-A profile can also add tools, libraries and setup to its runner pods when they start, rather than baking them into a runner image someone has to build, publish and patch: `capabilities` names entries of `github_runner_arc_capabilities`. A tool-cache capability is a public, pinned image holding a tool in the Actions tool-cache layout; an init container copies it into the runner's `RUNNER_TOOL_CACHE`, where `actions/setup-node`, `setup-tflint` and other setup actions that consult the cache find it and skip their download, and it can also be put on `PATH` for a tool no setup action looks up. A system-library capability is a public, pinned image holding a relocatable install prefix (shared libraries, headers, pkg-config files, programs) for what cannot live in the tool cache, such as an MPI implementation, a solver library or a database client library; an init container copies it into a sysroot (`/opt/sysroot` by default), and the job-started hook puts the sysroot on `PATH`, `LD_LIBRARY_PATH`, `LIBRARY_PATH`, `CPATH`, `PKG_CONFIG_PATH` and `CMAKE_PREFIX_PATH` and sets any relocation variable the library needs. A hook capability is a script run before each job's first step, through a job-started hook mounted from a ConfigMap. A profile with its own `runs_on_label` then works as a named runner, for example one with Terraform, TFLint and the AWS CLI, or one with Open MPI and a solver library, that workflows select with `runs-on`, all from one values file and the stock `actions-runner` image. `tool-images/` has Dockerfiles for reference tool images (Node.js, Terraform, TFLint, the AWS CLI) reference system-library images (Open MPI, HiGHS, GLPK, libpq, MariaDB Connector/C) and a reference build runner image (the stock runner image with a C toolchain, for jobs that compile against those libraries), which `.github/workflows/publish-tool-images.yml` publishes when started by hand or by a `tool-images-*` tag; `roles/github_runner_arc/README.md`'s Capabilities section has the tool-image and payload contracts, how each reference library is declared and proven to work from a relocated prefix, how to build an image of your own, and where capabilities apply.
+A profile can also add tools, libraries and setup to its runner pods when they start, rather than baking them into a runner image someone has to build, publish and patch: `capabilities` names entries of `github_runner_arc_capabilities`. A tool-cache capability is a public, pinned image holding a tool in the Actions tool-cache layout; an init container copies it into the runner's `RUNNER_TOOL_CACHE`, where `actions/setup-node`, `setup-tflint` and other setup actions that consult the cache find it and skip their download, and it can also be put on `PATH` for a tool no setup action looks up. A system-library capability is a public, pinned image holding a relocatable install prefix (shared libraries, headers, pkg-config files, programs) for what cannot live in the tool cache, such as an MPI implementation, a solver library or a database client library; an init container copies it into a sysroot (`/opt/sysroot` by default), and the job-started hook puts the sysroot on `PATH`, `LD_LIBRARY_PATH`, `LIBRARY_PATH`, `CPATH`, `PKG_CONFIG_PATH` and `CMAKE_PREFIX_PATH` and sets any relocation variable the library needs. A hook capability is a script run before each job's first step, through a job-started hook mounted from a ConfigMap. A node-cache capability is a directory of the node shared by the profile's runner pods there, for a package manager's store, which a pruner keeps under a size limit. A profile with its own `runs_on_label` then works as a named runner, for example one with Terraform, TFLint and the AWS CLI, or one with Open MPI and a solver library, that workflows select with `runs-on`, all from one values file and the stock `actions-runner` image. `tool-images/` has Dockerfiles for reference tool images (Node.js, Terraform, TFLint, the AWS CLI) reference system-library images (Open MPI, HiGHS, GLPK, libpq, MariaDB Connector/C) and a reference build runner image (the stock runner image with a C toolchain, for jobs that compile against those libraries), which `.github/workflows/publish-tool-images.yml` publishes when started by hand or by a `tool-images-*` tag; `roles/github_runner_arc/README.md`'s Capabilities section has the tool-image and payload contracts, how each reference library is declared and proven to work from a relocated prefix, how to build an image of your own, and where capabilities apply.
 
 ### Registry cache
 

autoscaler/Dockerfile

@@ -14,7 +14,8 @@ RUN apk add --no-cache bash curl jq kubectl
 COPY autoscaler/loop.sh /app/loop.sh
 COPY scripts/autoscaler.sh /app/scripts/autoscaler.sh
 COPY scripts/psi-reporter.sh /app/scripts/psi-reporter.sh
-RUN chmod +x /app/loop.sh /app/scripts/autoscaler.sh /app/scripts/psi-reporter.sh
+COPY scripts/node-cache-pruner.sh /app/scripts/node-cache-pruner.sh
+RUN chmod +x /app/loop.sh /app/scripts/autoscaler.sh /app/scripts/psi-reporter.sh /app/scripts/node-cache-pruner.sh
 
 WORKDIR /app
 ENTRYPOINT ["/app/loop.sh"]