Permission denied different steps are using a different workingDir (and one is a subdirectory of other's workdir step) #6842
Comments
|
Update: the same happens to me when using Tekton 0.47 and 0.48. steps:
- env: // ...
image: $(inputs.params.gitCloneInitImage)
name: git-clone
script: |-
#!/usr/bin/env sh
set -eu
CHECKOUT_DIR="$(workspaces.source.path)/repo"
git config --global --add safe.directory "$CHECKOUT_DIR"
/ko-app/git-init \
-url="${PARAM_URL}" \
-revision="${PARAM_REVISION}" \
-path="${CHECKOUT_DIR}"
cd "${CHECKOUT_DIR}"
RESULT_SHA="$(git rev-parse HEAD)"
EXIT_CODE="$?"
if [ "${EXIT_CODE}" != 0 ] ; then
exit "${EXIT_CODE}"
fi
workingDir: $(workspaces.source.path)
- command:
- $(inputs.params.projectBuilderCommand)
image: $(inputs.params.projectBuilderImage)
name: project-build
workingDir: $(workspaces.source.path)This works fine, but the second step fails because the cloned project is in a subdirectory, so this failure is expected. However: steps:
- env: // ...
image: $(inputs.params.gitCloneInitImage)
name: git-clone
script: |-
#!/usr/bin/env sh
set -eu
CHECKOUT_DIR="$(workspaces.source.path)/repo"
git config --global --add safe.directory "$CHECKOUT_DIR"
/ko-app/git-init \
-url="${PARAM_URL}" \
-revision="${PARAM_REVISION}" \
-path="${CHECKOUT_DIR}"
cd "${CHECKOUT_DIR}"
RESULT_SHA="$(git rev-parse HEAD)"
EXIT_CODE="$?"
if [ "${EXIT_CODE}" != 0 ] ; then
exit "${EXIT_CODE}"
fi
workingDir: $(workspaces.source.path)
- command:
- $(inputs.params.projectBuilderCommand)
image: $(inputs.params.projectBuilderImage)
name: project-build
workingDir: $(workspaces.source.path)/repo # this is the only change I did.This fails in the first step spites I didn't change anything in it. |
|
Another update (and found the root cause of the issue), my previous comment rings a bell to me since we were using another step to do more things. The full list of steps are: apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: spring-boot-with-tekton-example-build-and-deploy
spec:
params: // ...
steps:
- env: // ...
image: $(inputs.params.gitCloneInitImage)
name: git-clone
script: |-
#!/usr/bin/env sh
set -eu
CHECKOUT_DIR="$(workspaces.source.path)"
git config --global --add safe.directory "$CHECKOUT_DIR"
/ko-app/git-init \
-url="${PARAM_URL}" \
-revision="${PARAM_REVISION}" \
-path="${CHECKOUT_DIR}" <1>
cd "${CHECKOUT_DIR}"
RESULT_SHA="$(git rev-parse HEAD)"
EXIT_CODE="$?"
if [ "${EXIT_CODE}" != 0 ] ; then
exit "${EXIT_CODE}"
fi
workingDir: $(workspaces.source.path)
- args:
- "$(inputs.params.projectBuilderArgs[*])"
- -Duser.name=jcarvaja
- -Ddekorate.image-pull-secrets=spring-boot-with-tekton-example-registry-credentials
- -Ddekorate.docker.registry=quay.io
command:
- $(inputs.params.projectBuilderCommand)
image: $(inputs.params.projectBuilderImage)
name: project-build
workingDir: $(workspaces.source.path)
- args:
- "$(inputs.params.imageBuilderArgs[*])"
command:
- $(inputs.params.imageBuilderCommand)
env:
- name: DOCKER_CONFIG
value: /tekton/home/.docker
image: $(inputs.params.imageBuilderImage)
name: image-build
workingDir: $(workspaces.source.path)/examples/spring-boot-with-tekton # <2>
workspaces:
- description: The workspace to hold all project sources
name: source
readOnly: falseHaving set the Issue title updated with my findings. |
Sgitario
changed the title
|
@Sgitario thanks for the issue. This is kind-of a kubernetes / container runtime issue. When you set What this means is that any And all this is, kubernetes behavior, there is very little we could do on the Tekton side.
Quick additionnal note: you should migrate to use |
|
Actually, I stand corrected on this 😅. I did dig into @Sgitario so there is a slight chance that behavior gets better with 0.49 and above (0.50 would be the first LTS to have this fix) as #6515 will be part of 0.49 release. |
|
@vdemeester many thanks for your comment.
I did what you suggested here and I could move forward.
I will. Many thanks for noticing it! |
@vdemeester @Sgitario i am currently using v0.49 but still facing this issue :( Any suggestions on workarounds
|
|
just for the record , managed to get it work by adding |
|
Could the workingdirinit inherit the runAsUser from the podTemplate.securityContext? My task pod is created with runAsUser/runAsGroup/fsGroup all set to 65534 but the working directory is still created with ownership root:root |
|
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
tekton-robot
added
the
lifecycle/stale
|
/remove-lifecycle stale |
tekton-robot
removed
the
lifecycle/stale
I think that's something we should explore yes. |
Update: the actual issue and cause is described in this comment.
I have a task definition that creates an empty volume like:
Where
example-build-and-deployis:When running the workflow, it fails with:
I've found a similar issue #1872. However, the proposed solution didn't work for me (see the fsGroup and runAsUser)
Steps to Reproduce the Problem
I can prepare a reproducer, just let me know if you need it.
Additional Info
Kubernetes version:
Output of
kubectl version:Tekton Pipeline version:
Output of
tkn versionorkubectl get pods -n tekton-pipelines -l app=tekton-pipelines-controller -o=jsonpath='{.items[0].metadata.labels.version}'Note that I'm trying to migrate out from the PipelineResources like:
And it needs to be compatible when running a PipelineRun and TaskRun.
This work is part of the Dekorate Tekton extension: https://github.com/dekorateio/dekorate#tekton
The text was updated successfully, but these errors were encountered: