You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
apiVersion: tekton.dev/v1kind: PipelineRunmetadata:
name: ref-0001spec:
pipelineSpec:
tasks:
- name: task1taskSpec:
steps:
- name: step1image: ubuntuscript: | echo "Hello World from a TaskSpec!"
- name: task2taskRef:
resolver: gitparams:
- name: urlvalue: <git-repo>
- name: revisionvalue: main
- name: pathInRepovalue: bad-task.yaml
---
# where bad-task looks like:apiVersion: tekton.dev/v1kind: Taskmetadata:
name: bad-taskspec:
steps:
- image: ubuntufoo: bar
Notice that the field foo is not supposed to exist in the above Task.
At runtime, a validation error is expected when the remotely referenced resource is inspected.
In fact, if we kubectl apply the bad yaml to the cluster, we do get a webhook validation error.
Actual Behavior
The remote resolution discards the bad field foo and runs the rest of it so that error is not caught and the Task runs as if there was nothing wrong.
Issue
We use the universal deserializer to unmarshal the bytes to the pipeline struct.
@tektoncd/core-maintainers PTAL here 🙏 I think this is a bug that we should fix for consistent behavior and catch bad resources during remote resolution.
Expected Behavior
Notice that the field
foo
is not supposed to exist in the aboveTask
.At runtime, a validation error is expected when the remotely referenced resource is inspected.
In fact, if we
kubectl apply
the bad yaml to the cluster, we do get a webhook validation error.Actual Behavior
The remote resolution discards the bad field
foo
and runs the rest of it so that error is not caught and the Task runs as if there was nothing wrong.Issue
We use the
universal deserializer
to unmarshal the bytes to the pipeline struct.pipeline/pkg/remote/resolution/resolver.go
Line 100 in 13f45bf
The
CodecFactory
that is used here does not haveserializer.EnableStrict
as an argument. Hence, the unmarshilling process zaps the bad field.Solution
The following diff in the resolver code does the magic:
The text was updated successfully, but these errors were encountered: