Params + Results with nil Properties treated differently than Params + Results with empty Properties

[lbernick]

Expected Behavior

Our API doesn't differentiate between a map being nil and a map being empty.

The following two Task result definitions should be equivalent:

results:
  - name: my-result

results:
  - name: my-result
    properties: {}

Note: this is unrelated to the result values outputted by the TaskRun.

From the Go style guide: "Do not create APIs that force their clients to make distinctions between nil and the empty slice." (There's no equivalent guidance for maps but it seems like it should be the same?)

If we do want to differentiate this behavior we should at least make sure to document it clearly. I'm not sure why someone would want to declare an object param/result with no properties; it doesn't seem very meaningful.
Fixed in #6570 and #6578.

Actual Behavior

nil Properties -> defaults to string param/result:

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: nil-properties
spec:
  results:
    - name: object-results
  steps:
  - image: bash
    script: |
      echo -n "{\"IMAGE_URL\":\"ar.com\", \"IMAGE_DIGEST\":\"sha234\"}" > $(results.object-results.path)

$ k get task nil-properties -o yaml
...
spec:
  results:
  - name: object-results
    type: string
...

empty Properties -> defaults to object param/result

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: empty-properties
spec:
  results:
    - name: object-results
      properties: {}
  steps:
  - image: bash
    script: |
      echo -n "{\"IMAGE_URL\":\"ar.com\", \"IMAGE_DIGEST\":\"sha234\"}" > $(results.object-results.path)

$ k create -f ~/tkndefs/properties/nil-properties.yaml
Error from server (BadRequest): error when creating "/Users/leebernick/tkndefs/properties/nil-properties.yaml": admission webhook "validation.webhook.pipeline.tekton.dev" denied the request: validation failed: missing field(s): spec.results[0].object-results.properties

[JeromeJu]

Suggesting this can be closed. Thanks @lbernick

[lbernick]

@JeromeJu I think this bug can still be reproduced, even if conversion logic has been addressed

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.