Dashboard: Dashboard UI for Triggers

Created on 9 Sep 2019 · 15Comments · Source: tektoncd/dashboard

I think the trigger work solves a really critical problem -- mapping events to pipelineruns and resources. This issue is to look at what we might do to formally add it to the dashboard and also integrate it in with any pipelineruns and pipelineresources the trigger template creates in response to an event.

Epic design-help-wanted

Source

skaegi

👍1

Most helpful comment

PR created for the APIs that the panelling can leverage, this should open the flood gates 🎉

a-roberts on 1 Nov 2019

🎉2

All 15 comments

It might be helpful to define what a trigger is. Sounds like it's an "event." Can we list some examples of such events? What is a "trigger template?"

Based on this description, it sounds like we will need a page with a table containing said triggers. What descriptive columns will be needed on the table? Based on that, we can figure out what this page would link to within the dasbhoard.

Also, based on this description, it looks like a piece of this (triggers) might reside on the actual resource that was created as a result of said trigger. Whether it be PLR, or any other resource.
Looking forward to further conversation on this.

Would also like to note that it was stated that these Pipeline or Trigger templates are really at the top of the whole process... before the PipleinRun. (keep me honest if I'm stating this incorrectly).

Also that we'd like to have this implemented in the dashboard in the Oct-Nov. time frame

kimholmes on 11 Sep 2019

The triggers here refer to the Triggers project: https://github.com/tektoncd/triggers. The work is still in-progress (and pre-alpha), so the Custom Resources (EventListener, TriggerBinding, and TriggerTemplate) are still changing as we develop them.

When we prioritize this work item and someone picks it up, then I will be happy to help create the specifications for how the Dashboard should deal with Triggers resources 👍

Note: we might find it helpful to break this into separate issues for the EventListener, TriggerBinding, and TriggerTemplate

ncskier on 11 Sep 2019

Need to begin design work on this by the end of September.

kimholmes on 16 Sep 2019

Here's an overview of the Triggers resources at the moment (the project is still in development, so it is subject to change). Much of this information is re-iterated from the Triggers README's.

Overview

The Triggers project enables users to set up Tekton PipelineRuns/TaskRuns that will execute (start running) when an event is received. A common example use-case for Triggers is automatically creating of a PipelineResource, and PipelineRun after receiving a webhook from GitHub.

There are three custom resources in the Triggers project: TriggerTemplate, TriggerBinding, and EventListener. We would probably want a "list" page for each resource type, and maybe a "details" page as well if a user clicks on an item in the list; for example, a page listing all of the EventListener resources, and a "details" page when the user clicks on an EventListener.

tl;dr (this comment is long and throws a lot of information at you)

Focus on the __Important information to display in the details page__ sections for the important information to include in the details page for each resource.

1. TriggerTemplate

The TriggerTemplate specifies the resources a user would like to automatically create when an event is received.

Here's an example TriggerTemplate from the Triggers' examples.

apiVersion: tekton.dev/v1alpha1
kind: TriggerTemplate
metadata:
  name: pipeline-template
spec:
  params:
  - name: gitrevision
    description: The git revision
    default: master
  - name: gitrepositoryurl
    description: The git repository url
  - name: message
    description: The message to print
    default: This is the default message
  - name: contenttype
    description: The Content-Type of the event
  resourcetemplates:
  - apiVersion: tekton.dev/v1alpha1
    kind: PipelineResource
    metadata:
      name: git-source-$(uid)
    spec:
      type: git
      params:
      - name: revision
        value: $(params.gitrevision)
      - name: url
        value: $(params.gitrepositoryurl)
  - apiVersion: tekton.dev/v1alpha1
    kind: PipelineRun
    metadata:
      generateName: simple-pipeline-run
    spec:
      pipelineRef:
        name: simple-pipeline
      params:
      - name: message
        value: $(params.message)
      - name: contenttype
        value: $(params.contenttype)
      resources:
      - name: git-source
        resourceRef:
          name: git-source-$(uid)

In this example, the TriggerTemplate defines a PipelineResource and PipelineRun that will be created when an event is received. This TriggerTemplate also defines four parameters (gitrevision, gitrepositoryurl, message, and contenttype) that are used in the resourcetemplates.

Important information to display in the details page:

params (this is the list of inputs to the TriggerTemplate)
- each parameter must have a name, and can optionally have a default and/or description value
resourcetemplates (this is the list of resources that the TriggerTemplate will create)
- it would probably be helpful to display at least the kind and name of each resourcetemplate; maybe also a YAML snippet from the TriggerTemplate

2. TriggerBinding

When an event is received, it will have a payload with important data. The TriggerBinding specifies what data from the event payload will be passed to a TriggerTemplate. The TriggerTemplate passes this data to the TriggerTemplate as parameters (params)

Here's an example TriggerBinding from the Triggers' examples.

apiVersion: tekton.dev/v1alpha1
kind: TriggerBinding
metadata:
  name: pipeline-binding
spec:
  params:
  - name: gitrevision
    value: $(body.head_commit.id)
  - name: gitrepositoryurl
    value: $(body.repository.url)
  - name: contenttype
    value: $(header.Content-Type)

Important information to display in the details page:

params; each parameter has a name and value
- These params are different from the TriggerTemplate's params

3. EventListener

The EventListener will probably have the most information out of all the Triggers resources, it puts all of the resources together into a working bundle.

The EventListener creates a Pod that listens for events; it specifies what TriggerTemplate and TriggerBinding should be used when an event is received. It also specifies static params to pass to the TriggerTemplate, and an interceptor to validate the incoming event's authenticity.

The EventListener can have multiple TriggerTemplate + TriggerBinding bundles, and these are listed as the triggers property.

Here's an example EventListener from the Triggers' examples.

apiVersion: tekton.dev/v1alpha1
kind: EventListener
metadata:
  name: listener-interceptor
spec:
  serviceAccountName: tekton-triggers-example-sa
  triggers:
    - name: foo-trig
      interceptor:
        header:
        - name: Foo-Trig-Header1
          value: string-value
        - name: Foo-Trig-Header2
          value:
          - array-val1
          - array-val2
        objectRef:
          kind: Service
          name: gh-validate
          apiVersion: v1
          namespace: default
      binding:
        name: pipeline-binding
      template:
        name: pipeline-template
      params:
      - name: message
        value: Hello from the Triggers EventListener!
  status:
    address:
      hostname: el-listener.default.svc.cluster.local
    conditions:
    - lastTransitionTime: "2019-10-18T19:28:16Z"
      message: Deployment has minimum availability.
      reason: MinimumReplicasAvailable
      status: "True"
      type: Available
    - lastTransitionTime: "2019-10-18T19:28:14Z"
      message: Deployment exists
      status: "True"
      type: Deployment
    - lastTransitionTime: "2019-10-18T19:28:16Z"
      message: ReplicaSet "el-listener-9cb97455d" has successfully progressed.
      reason: NewReplicaSetAvailable
      status: "True"
      type: Progressing
    - lastTransitionTime: "2019-10-18T19:28:14Z"
      message: Service exists
      status: "True"
      type: Service
    configuration:
      generatedName: el-listener

Important information to display in the details page:

triggers (this is a list of TriggerTemplate + TriggerBinding pairs that will be triggered when an event is received)
- triggers.binding (this is the TriggerBinding associated with the EventListener's trigger)
- it might be helpful if this is able to link to the associated TriggerBinding description page
- triggers.template (this is the TriggerTemplate associated with the EventListener's trigger)
- it might be helpful if this is able to link to the associated TriggerTemplate description page
- triggers.params (this is a list of static parameters that are passed to the TriggerTemplate)
- each parameter has a name and value (these params are different from the TriggerTemplate's params)
- triggers.interceptor (this points to a Service that will verify the event's authenticity)
- objectRef (this points to a Service)
- header (this is a list of static inputs that are passed to the Interceptor)
  - each has a name and value
serviceAccountName
status
- address (this is the address of the EventListener's service)
- conditions (this determines whether the EventListener's Deployment & Service are running or have an error)

ncskier on 20 Sep 2019

First pass at triggers.
Questions:

Do we need create and delete on the main list view pages?
For the detail pages, what parts are editable, if any?
Do the trigger components have labels?
Should the "code" tab exist? If so, should it be called anything except "code?"

TriggerTemplate

main:
trigger_template_main

Should the columns in the Resource Templates table be switched? Kind, then name?
detail:
trigger_template_detail
code:
trigger_template_code

TriggerBinding

main:
trigger_binding_main
detail:
trigger_binding_detail
code:
trigger_binding_code

EventListeners

main:
eventlistener_main

How many multiple Bundles could there be? How many Validate Triggers could there be?
detail:
eventlistener_detail
code:
eventlistener_code

kimholmes on 4 Oct 2019

Updates to screens per last review with dev team:

For all detail pages, I changed the "code" tab to say "YAML." I also removed the edit button as these will be uneditable.
For TriggersTemplate I removed the word "value" from the table headers. Also, the PLR in the Resource Template table will not be inked.

For EventListeners I added a status and Service Account to the list view:
EventListener_main2
On the Detail page, I moved the Params into the first table and added triggers.validate which consists of the task.ref:
EventListener_detail2

kimholmes on 14 Oct 2019

Thanks for the updates @kimholmes! I think the updated TriggerTemplate page looks really good 👍

For the EventListeners list page, I like the addition of a Status column, but I'm not sure if we'll be able to use a checkmark icon as the value. Right now, the status just indicates that a pod is running, it does not indicate whether the latest build has been successful, or something like that (which is what the checkmark makes me think of).

For the EventListener's details page, I think that the table is an improvement, but the structure is still not exactly accurate, because each trigger can have multiple parameters. Also, the structure just changed a little to this (so the Validate is now called Interceptor):

spec:
  serviceAccountName: tekton-triggers-example-sa
  triggers:
    - name: foo-trig
      interceptor:
        header:
        - name: Foo-Trig-Header1
          value: string-value
        - name: Foo-Trig-Header2
          value:
          - array-val1
          - array-val2
        objectRef:
          kind: Service
          name: gh-validate
          apiVersion: v1
          namespace: default
      binding:
        name: pipeline-binding
      template:
        name: pipeline-template
      params:
      - name: message
        value: Hello from the Triggers EventListener!

I think that it might be beneficial to have a separate table for each trigger, and this table will be the list of params with columns for name and value.

Thanks again for the updates!

ncskier on 15 Oct 2019

@ncskier I think you provided an idea for this design in your sketch. Thank you!

kimholmes on 30 Oct 2019

👍1

PR created for the APIs that the panelling can leverage, this should open the flood gates 🎉

a-roberts on 1 Nov 2019

🎉2

/assign