triggers: Incorrect capitalization in fields treated differently b/w first creation + updates

Expected Behavior

When I make a change to a TriggerTemplate it should change!

Actual Behavior

When I apply a TriggerTemplate and subsequently try to make changes to it, the changes are never reflected in the state of the TriggerTemplate! I have to delete the TriggerTemplate and re-apply it to see the change.

Steps to Reproduce the Problem

  1. Apply a Trigger template such as:
---
apiVersion: triggers.tekton.dev/v1alpha1
kind: TriggerTemplate
metadata:
  name: unused-triggertemplate
spec:
  resourceTemplates:
  - apiVersion: tekton.dev/v1beta1
    kind: PipelineRun
    metadata:
      name: sad-pr-$(uid)
    spec:
      pipelineSpec:
        tasks:
        - name: be-sad
          taskSpec:
            steps:
            - name: sad
              image: ubuntu
              script: |
                #/bin/bash
                set -ex
                echo "happy"
  1. Make a change to the template and apply, e.g.:
---
apiVersion: triggers.tekton.dev/v1alpha1
kind: TriggerTemplate
metadata:
  name: unused-triggertemplate
spec:
  resourceTemplates:
  - apiVersion: tekton.dev/v1beta1
    kind: PipelineRun
    metadata:
      name: sad-pr-$(uid)
    spec:
      pipelineSpec:
        tasks:
        - name: be-sad
          taskSpec:
            steps:
            - name: sad
              image: ubuntu
              script: |
                #/bin/bash
                set -ex
                echo "preplexed or is it perplex"
  1. Retrieve the TriggerTemplate with kubectl - and note that it still uses the first value (i.e. “happy” in the case above) but bizarrely the last-applied-configuration does reflect the values we tried to change (i.e. “perplexed” above), e.g:
k get triggertemplates -o yaml unused-triggertemplate
apiVersion: triggers.tekton.dev/v1alpha1
kind: TriggerTemplate
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"triggers.tekton.dev/v1alpha1","kind":"TriggerTemplate","metadata":{"annotations":{},"name":"unused-triggertemplate","namespace":"default"},"spec":{"resourceTemplates":[{"apiVersion":"tekton.dev/v1beta1","kind":"PipelineRun","metadata":{"name":"sad-pr-$(uid)"},"spec":{"pipelineSpec":{"tasks":[{"name":"be-sad","taskSpec":{"steps":[{"image":"ubuntu","name":"sad","script":"#/bin/bash\nset -ex\necho \"preplexed or is it perplex\"\n"}]}}]}}}]}}
  creationTimestamp: "2020-04-07T16:25:09Z"
  generation: 1
  name: unused-triggertemplate
  namespace: default
  resourceVersion: "20694699"
  selfLink: /apis/triggers.tekton.dev/v1alpha1/namespaces/default/triggertemplates/unused-triggertemplate
  uid: 808ade7d-acc1-41f9-9f36-599e88b444f2
spec:
  resourcetemplates:
  - apiVersion: tekton.dev/v1beta1
    kind: PipelineRun
    metadata:
      name: sad-pr-$(uid)
    spec:
      pipelineSpec:
        tasks:
        - name: be-sad
          taskSpec:
            steps:
            - image: ubuntu
              name: sad
              script: |
                #/bin/bash
                set -ex
                echo "happy"

Note that I am not even using an eventlistener or referring to unused-triggertemplate anywhere! At first I thought the event listener might be doing this but it’s not involved at all afaik!

(I am using the latest triggers from HEAD https://github.com/tektoncd/triggers/commit/b44648c9bed0f8c55c1bef2217782f201b309974)

Additional Info

My only guess for what could be causing this is a webhook? I’m kinda stumped tho!

Also this might be something I’m not understanding that I need to do differently and not a bug at all? However I haven’t seen this behavior with any other CRDs so not sure!

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 35 (17 by maintainers)

Commits related to this issue

Most upvoted comments

In the repro case we were using resourceTemplates instead of resourcetemplates 😅 Looks like if you create a CRD with a field having the wrong case, it gets automatically corrected, but apply afterward doesnt do that b/c it just generates a patch containing the field with the wrong capitalization which is then IGNORED X’D

It’s possible that open API validation will help here, some related issues from pipeline:

My hunch is that it has something to do with just the resourceTemplates since they get stored as “rawMessage”/“unstructured” unlike the regular fields