You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Let runner pods share a node-local package cache #83
Every runner pod starts with an empty work volume and an empty home, so each job restores its package manager's store or its installed dependency tree from the Actions cache and unpacks it into a fresh filesystem. On a node running several pods that is a lot of small-file writes at the same time, and the writes are repeated for each job although the content is identical between them.
A cache volume that lives on the node and is shared by its runner pods would turn most of that into reads from the page cache: a pnpm store or a similar content-addressed cache, restored once per node and updated by whichever job misses.
What makes it less simple than a hostPath mount:
Hard links, which are what make a pnpm store nearly free to install from, fail across mount points even on one filesystem, so a store on one mount and a work directory on another falls back to copying, which is cheaper than unpacking an archive but still writes every file. Getting the links needs the store and the work directory under one mount, so the work directory would have to move onto the same hostPath volume, per pod, with the runner's workspace path resolving into it.
Concurrent jobs write the store at the same time. pnpm's store is built for that, others may not be.
The pods must not be able to poison each other: a job that writes a bad file into a shared store affects every later job on the node. A store keyed by content hash and verified on use limits that, and the cache should be opt-in per capability.
Workflows have to stay portable to GitHub-hosted runners, so the volume is a speed-up the workflow detects (a path that exists) with its existing cache step as the fallback.
The capability mechanism from #55 looks like the right home: a capability that mounts a node-local volume and sets the package manager's environment, with the volume's lifetime and size limit set by the role.
First step worth doing before building anything: measure how much of a job's writes are cache restore and unpack, on a node under pressure, so the gain is known.
Implemented by #90 and released in v1.31.0: the node-cache capability and its pruner. A hard link cannot cross the mount between the shared store and a pod's workspace (checked on Linux), so the design relies on pnpm's global virtual store, which links with symbolic links.
Activity
Mearman commentedon Oct 14, 2026
Implemented by #90 and released in v1.31.0: the node-cache capability and its pruner. A hard link cannot cross the mount between the shared store and a pod's workspace (checked on Linux), so the design relies on pnpm's global virtual store, which links with symbolic links.