argoproj / argoproj/argo-workflows
Mount `input-artifacts` into `initContainers`
- Dominant language
- Go
- Stars
- 17k
- Forks
- 3.7k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 138
Description
# Summary
Currently `initContainers` can't access `input: artifacts`.
Workaround:
```yaml
podSpecPatch: | #can't specify it directly because then it fails validation
initContainers:
- name: summation
volumeMounts:
- mountPath: /data
name: input-artifacts #have to manually add the data directory to initContainers, unfortunately - hope Argo don't change their internals on this
subPath: data
```
Given the structure of the Workflow yaml, I'd naturally assumed that the `input-artifacts` would be mounted into `initContainers` also.
# Use Cases
Due to a lack of a `when` clause on output artifacts I have a `initContainer` doing the real work which needs the artifacts and a `container` whose code conditionally copies them to a different file path and then making the artifacts optional.
I also commonly use an initContainer pattern as storage is difficult in EKS where we can't assume Workflow Pods will be scheduled in the same availability zone to use EBS backed PVCs.
---
**Message from the maintainers**:
Love this enhancement proposal? Give it a 👍. We prioritise the proposals with the most 👍.
Contributor guide
Research direction
Start by tracing workflow pod generation for how input artifacts are mounted, then compare the regular container and initContainer paths and review validation around podSpecPatch. Done means input-artifacts are available to initContainers without a manual patch, with coverage for the described workflow structure.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- backend, infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100