Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pipeline fails with default array params when type is not specified in remote resource #7775

Closed
l-qing opened this issue Mar 19, 2024 · 1 comment · Fixed by #7776
Closed
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@l-qing
Copy link
Contributor

l-qing commented Mar 19, 2024

Expected Behavior

When defining default parameters within a remote resource, if the default value is an array, the pipeline should accept the default array value and proceed with execution without any issues, even if the parameter type is not explicitly set.

Actual Behavior

If a param in the remote resource definition does not have the type specified and the default value given is an array, the pipeline execution fails.

Steps to Reproduce the Problem

  1. Execute the following script:
kubectl apply -f - <<EOF
apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: mock-task-run
spec:
  taskRef:
    resolver: http
    params:
      - name: url
        value: https://raw.githubusercontent.com/l-qing/catalog/chore/test-array-params-in-resolver/task/test-array-params-in-resolver.yaml
  params:
    - name: tags
      value:
        - latest
        - v1
        - v2

---
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: mock-pipeline-run
spec:
  pipelineRef:
    resolver: http
    params:
      - name: url
        value: https://raw.githubusercontent.com/l-qing/catalog/chore/test-array-params-in-resolver/pipeline/test-array-params-in-resolver.yaml
  params:
    - name: tags
      value:
        - latest
        - v1
        - v2
EOF
  1. Task definition
apiVersion: tekton.dev/v1beta1
kind: ClusterTask
metadata:
  name: mock-task
spec:
  params:
    - name: tags
      # type: array         <- The type is not set
      default:
        - latest
        - v1
        - v2

  steps:
    - image: ubuntu
      name: mock
      resources:
        requests:
          cpu: 50m
          memory: 50Mi
        limits:
          cpu: 50m
          memory: 50Mi
      args:
        - --tags
        - $(params.tags[*])
      script: |
        #!/bin/bash

        tags=()
        parsing_flag=""
        echo "args are $@"
        for arg in "$@"; do
            # flag keys
            if [ "$arg" == "--tags" ]; then
                echo "-> Parsing tags variables..."
                parsing_flag="tags"
            # flag values
            elif [ "$parsing_flag" == "tags" ] && [ "$arg" != "" ]; then
                tags+=("$arg")
            fi
        done
        echo "tags are ${tags[@]}"
  1. Pipeline definition
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: mock-pipeline
spec:
  params:
    - name: tags
      default:
        - pr-latest
  tasks:
    - name: task-1
      taskRef:
        resolver: http
        params:
          - name: url
            value: https://raw.githubusercontent.com/l-qing/catalog/chore/test-array-params-in-resolver/task/test-array-params-in-resolver.yaml
    - name: task-2
      taskRef:
        resolver: http
        params:
          - name: url
            value: https://raw.githubusercontent.com/l-qing/catalog/chore/test-array-params-in-resolver/task/test-array-params-in-resolver.yaml
      params:
        - name: tags
          value: $(params.tags[*])
  1. TaskRun Results
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
status:
  completionTime: "2024-03-19T06:49:36Z"
  conditions:
  - lastTransitionTime: "2024-03-19T06:49:36Z"
    message: 'validation failed for referenced object mock-task: admission webhook
      "validation.webhook.pipeline.tekton.dev" denied the request: validation failed:
      "string" type does not match default value''s type: "array": spec.params.tags.default.type,
      spec.params.tags.type'
    reason: TaskValidationFailed
    status: "False"
    type: Succeeded
  1. PipelineRun Results
apiVersion: tekton.dev/v1
kind: PipelineRun
status:
  completionTime: "2024-03-19T06:49:36Z"
  conditions:
  - lastTransitionTime: "2024-03-19T06:49:36Z"
    message: '[User error] Pipeline /mock-pipeline can''t be Run; it has an invalid
      spec: "string" type does not match default value''s type: "array": finally.params.tags.default.type,
      finally.params.tags.type, tasks.params.tags.default.type, tasks.params.tags.type'
    reason: PipelineValidationFailed
    status: "False"
    type: Succeeded
  pipelineSpec:
    params:
    - default:
      - pr-latest
      name: tags
      type: string
    tasks:
    - name: task-1
      taskRef:
        kind: Task
        params:
        - name: url
          value: https://raw.githubusercontent.com/l-qing/catalog/chore/test-array-params-in-resolver/task/test-array-params-in-resolver.yaml
        resolver: http
    - name: task-2
      params:
      - name: tags
        value: $(params.tags[*])
      taskRef:
        kind: Task
        params:
        - name: url
          value: https://raw.githubusercontent.com/l-qing/catalog/chore/test-array-params-in-resolver/task/test-array-params-in-resolver.yaml
        resolver: http

Additional Info

  • Kubernetes version:

    Output of kubectl version:

Client Version: v1.29.3
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.8
  • Tekton Pipeline version:

    Output of tkn version or kubectl get pods -n tekton-pipelines -l app=tekton-pipelines-controller -o=jsonpath='{.items[0].metadata.labels.version}'

Client version: 0.35.1
Pipeline version: v0.56.2
@l-qing l-qing added the kind/bug Categorizes issue or PR as related to a bug. label Mar 19, 2024
@l-qing
Copy link
Contributor Author

l-qing commented Mar 19, 2024

/assign @l-qing

l-qing added a commit to l-qing/pipeline that referenced this issue Mar 19, 2024
…ne failures

fix tektoncd#7775

In the existing logic, resources used for ConvertTo should have default values set.
Otherwise, there could be issues with incorrect parameter types being set
(e.g., an array type being treated as a string type).

However, resources fetched from remote sources haven't undergone the SetDefaults
operation. If we directly invoke the ConvertTo operation, it might result in
erroneous outcomes.

For instance, a v1beta1 ClusterTask that undergoes a direct ConvertTo to convert
the resource into a v1 Task for validation might be mistakenly considered invalid.

Additionally, even if a v1beta1 Task passes validation, the process of converting
it to a v1 Task could still incorrectly set default parameter types, leading to
errors during execution.
l-qing added a commit to l-qing/pipeline that referenced this issue Mar 19, 2024
…ne failures

fix tektoncd#7775

In the existing logic, resources used for ConvertTo should have default values set.
Otherwise, there could be issues with incorrect parameter types being set
(e.g., an array type being treated as a string type).

However, resources fetched from remote sources haven't undergone the SetDefaults
operation. If we directly invoke the ConvertTo operation, it might result in
erroneous outcomes.

For instance, a v1beta1 ClusterTask that undergoes a direct ConvertTo to convert
the resource into a v1 Task for validation might be mistakenly considered invalid.

Additionally, even if a v1beta1 Task passes validation, the process of converting
it to a v1 Task could still incorrectly set default parameter types, leading to
errors during execution.
l-qing added a commit to l-qing/pipeline that referenced this issue Mar 21, 2024
…ne failures

fix tektoncd#7775

In the existing logic, resources used for ConvertTo should have default values set.
Otherwise, there could be issues with incorrect parameter types being set
(e.g., an array type being treated as a string type).

However, resources fetched from remote sources haven't undergone the SetDefaults
operation. If we directly invoke the ConvertTo operation, it might result in
erroneous outcomes.

For instance, a v1beta1 ClusterTask that undergoes a direct ConvertTo to convert
the resource into a v1 Task for validation might be mistakenly considered invalid.

Additionally, even if a v1beta1 Task passes validation, the process of converting
it to a v1 Task could still incorrectly set default parameter types, leading to
errors during execution.
l-qing added a commit to l-qing/pipeline that referenced this issue Apr 3, 2024
…ne failures

fix tektoncd#7775

In the existing logic, resources used for ConvertTo should have default values set.
Otherwise, there could be issues with incorrect parameter types being set
(e.g., an array type being treated as a string type).

However, resources fetched from remote sources haven't undergone the SetDefaults
operation. If we directly invoke the ConvertTo operation, it might result in
erroneous outcomes.

For instance, a v1beta1 ClusterTask that undergoes a direct ConvertTo to convert
the resource into a v1 Task for validation might be mistakenly considered invalid.

Additionally, even if a v1beta1 Task passes validation, the process of converting
it to a v1 Task could still incorrectly set default parameter types, leading to
errors during execution.
l-qing added a commit to l-qing/pipeline that referenced this issue Apr 9, 2024
…ne failures

fix tektoncd#7775

In the existing logic, resources used for ConvertTo should have default values set.
Otherwise, there could be issues with incorrect parameter types being set
(e.g., an array type being treated as a string type).

However, resources fetched from remote sources haven't undergone the SetDefaults
operation. If we directly invoke the ConvertTo operation, it might result in
erroneous outcomes.

For instance, a v1beta1 ClusterTask that undergoes a direct ConvertTo to convert
the resource into a v1 Task for validation might be mistakenly considered invalid.

Additionally, even if a v1beta1 Task passes validation, the process of converting
it to a v1 Task could still incorrectly set default parameter types, leading to
errors during execution.
l-qing added a commit to l-qing/pipeline that referenced this issue Apr 13, 2024
…ne failures

fix tektoncd#7775

In the existing logic, resources used for ConvertTo should have default values set.
Otherwise, there could be issues with incorrect parameter types being set
(e.g., an array type being treated as a string type).

However, resources fetched from remote sources haven't undergone the SetDefaults
operation. If we directly invoke the ConvertTo operation, it might result in
erroneous outcomes.

For instance, a v1beta1 ClusterTask that undergoes a direct ConvertTo to convert
the resource into a v1 Task for validation might be mistakenly considered invalid.

Additionally, even if a v1beta1 Task passes validation, the process of converting
it to a v1 Task could still incorrectly set default parameter types, leading to
errors during execution.
l-qing added a commit to l-qing/pipeline that referenced this issue Apr 23, 2024
…ne failures

fix tektoncd#7775

In the existing logic, resources used for ConvertTo should have default values set.
Otherwise, there could be issues with incorrect parameter types being set
(e.g., an array type being treated as a string type).

However, resources fetched from remote sources haven't undergone the SetDefaults
operation. If we directly invoke the ConvertTo operation, it might result in
erroneous outcomes.

For instance, a v1beta1 ClusterTask that undergoes a direct ConvertTo to convert
the resource into a v1 Task for validation might be mistakenly considered invalid.

Additionally, even if a v1beta1 Task passes validation, the process of converting
it to a v1 Task could still incorrectly set default parameter types, leading to
errors during execution.
l-qing added a commit to l-qing/pipeline that referenced this issue Apr 24, 2024
…ne failures

fix tektoncd#7775

In the existing logic, resources used for ConvertTo should have default values set.
Otherwise, there could be issues with incorrect parameter types being set
(e.g., an array type being treated as a string type).

However, resources fetched from remote sources haven't undergone the SetDefaults
operation. If we directly invoke the ConvertTo operation, it might result in
erroneous outcomes.

For instance, a v1beta1 ClusterTask that undergoes a direct ConvertTo to convert
the resource into a v1 Task for validation might be mistakenly considered invalid.

Additionally, even if a v1beta1 Task passes validation, the process of converting
it to a v1 Task could still incorrectly set default parameter types, leading to
errors during execution.
tekton-robot pushed a commit that referenced this issue Apr 25, 2024
…ne failures

fix #7775

In the existing logic, resources used for ConvertTo should have default values set.
Otherwise, there could be issues with incorrect parameter types being set
(e.g., an array type being treated as a string type).

However, resources fetched from remote sources haven't undergone the SetDefaults
operation. If we directly invoke the ConvertTo operation, it might result in
erroneous outcomes.

For instance, a v1beta1 ClusterTask that undergoes a direct ConvertTo to convert
the resource into a v1 Task for validation might be mistakenly considered invalid.

Additionally, even if a v1beta1 Task passes validation, the process of converting
it to a v1 Task could still incorrectly set default parameter types, leading to
errors during execution.
l-qing added a commit to katanomi/pipeline that referenced this issue Apr 29, 2024
…ne failures

fix tektoncd#7775

In the existing logic, resources used for ConvertTo should have default values set.
Otherwise, there could be issues with incorrect parameter types being set
(e.g., an array type being treated as a string type).

However, resources fetched from remote sources haven't undergone the SetDefaults
operation. If we directly invoke the ConvertTo operation, it might result in
erroneous outcomes.

For instance, a v1beta1 ClusterTask that undergoes a direct ConvertTo to convert
the resource into a v1 Task for validation might be mistakenly considered invalid.

Additionally, even if a v1beta1 Task passes validation, the process of converting
it to a v1 Task could still incorrectly set default parameter types, leading to
errors during execution.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant