-
Notifications
You must be signed in to change notification settings - Fork 86
Open
Description
Summary
Hello, I am currently experimenting with the new kubernetes-novolume mode and while evaluating our different use cases, I noticed that there is no logic to copy the final workspace state of a container step before deleting the pod running it.
Is it an expected breaking change with this new approach ? In the v0.7.0, the updates done by a container step to the workspace are available to the following steps running the main job pod.
Example
jobs:
job1:
runs-on: self-hosted
container:
image: xxx
steps:
- name: Checkout repository
uses: actions/checkout@v4
# Add a foo.txt file in the workspace folder
- name: Do something in container
uses: docker://xxx
# Read the foo.txt file > file not found
- name: Read file foo.txt
run: |
cat foo.txt
shell: bash
Investigation
I found the following code during my investigation. Is it expected that after running execPodStep, the pod is directly deleted for the container step case ?
// run-container-step.ts
l90 => await execCpFromPod(getJobPodName(), `/__w`, `${runnerWorkspace}`)
l92 => writeContainerStepScript()
l100 => execCpToPod(podName, `${runnerWorkspace}/__w`, '/__w')
l106 => execPodStep(
['/__e/sh', '-e', containerPath],
pod.metadata.name,
JOB_CONTAINER_NAME
)
l122 => await deletePod(podName)// run-script-step.ts
l27 => await execCpToPod(state.jobPod, runnerTemp, containerTemp)
l33 => await execPodStep(
[args.entryPoint, ...args.entryPointArgs],
state.jobPod,
JOB_CONTAINER_NAME
)
l54 => await execCpFromPod(state.jobPod, containerTemp, workdir)Thank you in advance for your support!
Metadata
Metadata
Assignees
Labels
No labels