Validation failed when using spec.results and spec.steps[].results on the same spec
When defining a Tekton Task that utilizes both spec.results and spec.steps[].results, the Task fails with a validation error. Specifically, the error indicates that the variables defined in spec.steps[].results cannot be accessed correctly within the step scripts, leading to a validation failure.
Error from server (BadRequest): error when creating "step-action.yaml": admission webhook "validation.webhook.pipeline.tekton.dev" denied the request: validation failed: non-existent variable in "#!/usr/bin/env sh\nset -x\nSINGLE_COMPONENT_MODE=\"scott\"\n\necho -n \"${SINGLE_COMPONENT_MODE}\" > $(step.results.singleComponentMode.path)\necho -n \"tom\" > $(results.resultsDir.path)\n": spec.steps[0].script
Expected Behavior
spec.results and spec.steps[].results working togother
Actual Behavior
spec.results and spec.steps[].results doesnt seem to work when used togother
Steps to Reproduce the Problem
- create the task and taskrun as the followin
---
apiVersion: tekton.dev/v1
kind: Task
metadata:
name: collect-data
spec:
results:
- name: resultsDir
type: string
steps:
- name: collect-data
image: quay.io/konflux-ci/release-service-utils:e633d51cd41d73e4b3310face21bb980af7a662f
results:
- name: singleComponentMode
type: string
script: |
#!/usr/bin/env sh
set -x
SINGLE_COMPONENT_MODE="scott"
echo -n "${SINGLE_COMPONENT_MODE}" > $(step.results.singleComponentMode.path)
echo -n "tom" > $(results.resultsDir.path)
- name: reduce
params:
- name: SINGLE_COMPONENT
value: $(steps.collect-data.results.singleComponentMode)
ref:
name: my-stepaction
---
apiVersion: tekton.dev/v1alpha1
kind: StepAction
metadata:
name: my-stepaction
spec:
params:
- name: SINGLE_COMPONENT
type: string
env:
- name: SINGLE_COMPONENT
value: $(params.SINGLE_COMPONENT)
image: quay.io/konflux-ci/release-service-utils:e633d51cd41d73e4b3310face21bb980af7a662f
script: |
#!/usr/bin/env bash
echo ${SINGLE_COMPONENT}
---
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
generateName: test-
spec:
taskRef:
name: collect-data
Additional Info
-
Kubernetes version:
Output of
kubectl version:
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short. Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.1", GitCommit:"4c9411232e10168d7b050c49a1b59f6df9d7ea4b", GitTreeState:"clean", BuildDate:"2023-04-14T13:14:41Z", GoVersion:"go1.20.3", Compiler:"gc", Platform:"darwin/amd64"}
Kustomize Version: v5.0.1
Server Version: version.Info{Major:"1", Minor:"28", GitVersion:"v1.28.0", GitCommit:"855e7c48de7388eb330da0f8d9d2394ee818fb8d", GitTreeState:"clean", BuildDate:"2023-08-15T21:24:51Z", GoVersion:"go1.20.7", Compiler:"gc", Platform:"linux/amd64"}
-
Tekton Pipeline version:
Output of
tkn versionorkubectl get pods -n tekton-pipelines -l app=tekton-pipelines-controller -o=jsonpath='{.items[0].metadata.labels.version}'
on:"go1.20.7", Compiler:"gc", Platform:"linux/amd64"}
➜ tekton tkn version
Client version: 0.37.0
Chains version: v0.22.0
Pipeline version: v0.63.0
Triggers version: v0.29.1
Dashboard version: v0.50.0
Operator version: devel
cc @chitrangpatel
The way it was designed was such that for an inlined Step, you don't need step results since an inlined Step is in the direct body (i.e. not referenced) of the Task so what you need is a Result.
Step Results were introduced so that StepActions (which are always referenced in some Task) have a way of declaring and robustly using results without fear of name clashes and overwriting etc.
In your example, I think you want to support both Result and a Step Result in an inlined Step which is a bit counter intuitive to me. Why not simply use Result?
Hi!
My example was a bit simplified.
But my scenario is:
PipelineRunreferencing aPipelinevia a git refPipelineusing 2 tasks via git refcollect-dataandapply-data
collect-datahas 3 steps:- 1 step defined inline with Taskspec
- 1 use of a
StepActionvia a git ref- This
StepActionaccepts parameters using results from the preceeding step.
- This
apply-dataalso accepts parameters with results determined withincollect-data
I crafted a reproducer here: https://github.com/scoheb/test-stepactions/tree/main/git-referenced
if you have any recommendations, please let me know!
thanks!
Ah I see. So you want to pass a param value which is a result of a previous step. There is no way to reference the Task result in another step. That is only possible in another Task within a pipeline.
I'm in agreement in that case that this should be supported.