actions / actions/runner-container-hooks
Multi-Attach error for volume XXX Volume is already used by pod(s) RUNNER POD
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 153
- Forks
- 112
- Avg merge
- 6m
- Merged PRs (30d)
- 1
Description
github runner in kubernetes mode expects kubernetesModeWorkVolumeClaim, the default is accessModes: ["ReadWriteOnce"], and in most of the doc it's always accessModes: ["ReadWriteOnce"].
However, in kubernetes mode, the runner container hook is expected to create new pod, get the volume from the runner pod and use it there, but it does't work since the ReadWriteOnce allows just 1 pod to be mounting the pvc, which is the runner pod, I've seen a lot of examples where aws gp3 storage class is used and no one has complained about the issue I'm facing!
I've tried to use EFS, it works fine, but the point is it's X15 slower than ebs, regardless, how the default is ReadWriteOnce and you expect it to work fine although, by definition, ReadWriteOnce doesn't work with more than one pod but the hook actually uses the same PVC of the runner in https://github.com/actions/runner-container-hooks/blob/9705deeb083452f326cb790231645a2618955bfa/packages/k8s/src/k8s/index.ts#L103
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at packages/k8s/src/k8s/index.ts around line 103 and trace how the runner pod's PVC is passed to the newly created pod. Compare that behavior with the documented ReadWriteOnce default and Kubernetes volume rules. Done means the supported storage behavior for this hook is established and reflected in the relevant implementation or documentation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, kubernetes, typescript
- Domain
- ci-cd, devops, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100