PipelineRun with no tasks passes validation?

[aThorp96]

Expected Behavior

In my mind, a pipelinerun with no tasks should not pass validation. If all tasks are skipped that's one thing, but if I create a PipelineRun with a pipelineSpec and don't list any tasks I can't think of a situation where that would be intentional or desirable. This can cause confusion in cases such as a yaml whitespace error

Actual Behavior

Right now such a task (example below) will be created without any validation errors or warnings and marked as Completed successfully upon their first reconciliation

apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: pipelinerun-with-just-description
spec:
  pipelineSpec:
    description: |
      This pipeline appears to have a good morning task!

      In actuality, even though the pipelinerun will be marked as valid, 
      a yaml indentation mistake means that the pipelineSpec only has a description field

      tasks:
        - name: echo-good-morning
          taskSpec:
            steps:
              - name: echo
                image: mirror.gcr.io/ubuntu
                script: |
                  #!/usr/bin/env bash
                  echo "Good Morning!"

Steps to Reproduce the Problem

1. Create the above pipelinerun
2. tkn pr desc pipelinerun-with-just-description
3. Observe the pipelinerun "ran" successfully

Additional Info

• Kubernetes version:

  Output of kubectl version:

 $ kubectl version
Client Version: v1.32.0
Kustomize Version: v5.5.0
Server Version: v1.32.0

• 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}'

$ tkn version
Client version: 0.41.0
Pipeline version: v1.2.0
Dashboard version: v0.55.0

The reason this happens appears to be that PipelineSpec validation ensures some field is present but it doesn't care which field is present. It's unclear to me if there is any use case for a PipelineSpec to have just a description, params, resources, or workspaces. It should be an easy fix, but if this is expected behavior then perhaps the fix should be in documentation or with a warning

Mirror of RedHat issue https://issues.redhat.com/browse/SRVKP-8190

[aThorp96]

CC @vdemeester