Move params into EventListener

Fixes tektoncd#88 Make TriggerBindings more reusable

This is the first pass at moving static parameters out of the
TriggerBinding. This implementation moves static parameters into the
EventListener where the user currently specifies all of the other static
information.

docs/create-webhook.yaml

@@ -6,61 +6,61 @@ spec:
   inputs:
     params:
     - name: CreateCertificate
-      description: Create certificate 
+      description: Create certificate
       default: "true"
     - name: CreateIngress
-      description: Create ingress 
+      description: Create ingress
       default: "true"
     - name: CreateWebhook
-      description: Create webhook 
+      description: Create webhook
       default: "true"
     - name: CreateEventListener
-      description: Create event listener 
+      description: Create event listener
       default: "true"
     - name: CertificateKeyPassphrase
-      description: The phrase that protects private key 
+      description: The phrase that protects private key
       default: "phrase1"
     - name: CertificateSecretName
-      description: The secret name for ingress certificate 
+      description: The secret name for ingress certificate
       default: "secret1"
     - name: ExternalUrl
-      description: The external access URl 
+      description: The external access URl
       default: "https://$(inputs.params.EventListenerName).PROXYIP.nip.io"
     - name: GithubOwner
       description: The github owner name
       default: "owner"
     - name: GithubRepo
-      description: The github repo name 
+      description: The github repo name
       default: "repo"
     - name: GithubSecretName
-      description: The secret name for github 
+      description: The secret name for github
       default: "githubsecret"
     - name: GithubAccessTokenKey
-      description: The key name for access token 
+      description: The key name for access token
       default: "accessToken"
     - name: GithubUserNameKey
-      description: The key name for github user name 
+      description: The key name for github user name
       default: "userName"
     - name: GithubSecretStringKey
-      description: The key name for github secret string 
+      description: The key name for github secret string
       default: "secretString"
     - name: GithubUrl
-      description: The url of git hub 
+      description: The url of git hub
       default: "github.com"
     - name: EventListenerName
-      description: The event listener name 
+      description: The event listener name
       default: "eventlistener"
     - name: TriggerBinding
-      description: The Trigger binding 
+      description: The Trigger binding
       default: "triggerbinding"
     - name: TriggerTemplate
-      description: The Trigger Template 
+      description: The Trigger Template
       default: "triggertemplate"
     - name: TriggerServiceAccount
-      description: The Trigger service account 
+      description: The Trigger service account
       default: "default"
     - name: ValidateTaskName
-      description: The event validation task name 
+      description: The event validation task name
       default: "validate-github-event"
   steps:
   - name: generate-certificate
@@ -99,7 +99,7 @@ spec:
       then
         exit 0
       fi
-      kubectl create secret tls $(inputs.params.CertificateSecretName) --cert=/var/tmp/work/ingress/certificate.pem --key=/var/tmp/work/ingress/key.pem 
+      kubectl create secret tls $(inputs.params.CertificateSecretName) --cert=/var/tmp/work/ingress/certificate.pem --key=/var/tmp/work/ingress/key.pem
       EOF
     volumeMounts:
     - name: work
@@ -194,6 +194,6 @@ spec:
   volumes:
   - name: github-secret
     secret:
-      secretName: $(inputs.params.GithubSecretName) 
+      secretName: $(inputs.params.GithubSecretName)
   - name: work
     emptyDir: {}

docs/eventlisteners.md

@@ -1,11 +1,18 @@
 # EventListener
-`EventListener`s connect `TriggerBinding`s to `TriggerTemplate`s and provide an addressable endpoint, which is where webhooks/events are directed.
+`EventListener`s connect `TriggerBinding`s to `TriggerTemplate`s and provide an
+addressable endpoint, which is where webhooks/events are directed.
 
-It also define an optional field called `validate` to validate event using a predefined task. Learn more here: [validate-event](validate-event.md).
+It also define an optional field called `validate` to validate event using a
+predefined task. Learn more here: [validate-event](validate-event.md).
 
-Further, it is as this level that the service account is connected, which specifies what permissions the resources will be created (or at least attempted) with.
+Further, it is at this level that the service account is connected, which
+specifies what permissions the resources will be created (or at least attempted)
+with.
 
-When an `EventListener` is successfully created, a service is created that references a listener pod. This listener pod accepts the incoming events and does what has been specified in the corresponding `TriggerBinding`s/`TriggerTemplate`s.
+When an `EventListener` is successfully created, a service is created that
+references a listener pod. This listener pod accepts the incoming events and
+does what has been specified in the corresponding
+`TriggerBinding`s/`TriggerTemplate`s.
 
 <!-- FILE: examples/eventlisteners/eventlistener.yaml -->
 ```YAML
@@ -18,6 +25,13 @@ spec:
   triggers:
     - binding:
         name: pipeline-binding
+        params:
+          - name: message
+            value: Hello from the Triggers EventListener!
       template:
         name: pipeline-template
 ```
+
+## Parameters
+`EventListener`s can provide `params` which are passed to the `TriggerBinding`
+specified by the `binding.name`. Each parameter has a `name` and a `value`.

docs/triggerbindings.md

@@ -1,7 +1,8 @@
 # TriggerBindings
 As per the name, `TriggerBinding`s bind against events/triggers.
-`TriggerBinding`s enable you to capture fields within an event payload and store them as parameters.
-The separation of `TriggerBinding`s from `TriggerTemplate`s was deliberate to encourage reuse between them.
+`TriggerBinding`s enable you to capture fields within an event payload and store
+them as parameters. The separation of `TriggerBinding`s from `TriggerTemplate`s
+was deliberate to encourage reuse between them.
 
 <!-- FILE: examples/triggerbindings/triggerbinding.yaml -->
 ```YAML
@@ -10,11 +11,35 @@ kind: TriggerBinding
 metadata:
   name: pipeline-binding
 spec:
-  params:
+  inputParams:
+    - name: message
+      description: The message to print
+      default: This is the default message
+  outputParams:
     - name: gitrevision
       value: $(event.head_commit.id)
     - name: gitrepositoryurl
       value: $(event.repository.url)
+    - name: message
+      value: $(inputParams.message)
 ```
 
 `TriggerBinding`s are connected to `TriggerTemplate`s within an [`EventListener`](eventlisteners.md), which is where the pod is actually instantiated that "listens" for the respective events.
+
+## Input Parameters
+`TriggerBinding`s can declare input parameters that are supplied by an
+`EventListener`. `inputParams` must have a `name`, and can have an optional
+`description` and `default` value.
+
+`inputParams` can be referenced in the `TriggerBinding` using the following
+variable substitution syntax, where `<name>` is the name of the input parameter:
+```YAML
+$(inputParams.<name>)
+```
+`inputParams` can be referenced in the `outputParams` section of a
+`TriggerBinding`. The purpose of `inputParams` is to make `TriggerBindings`
+reusable.
+
+## Output Parameters
+`TriggerBinding`s can provide output params which are passed to a
+`TriggerTemplate`. Each output parameter has a `name` and a `value`.

docs/triggertemplates.md

@@ -1,6 +1,7 @@
 # TriggerTemplates
 A `TriggerTemplate` is a resource that can template resources.
-`TriggerTemplate`s have optional parameters that can be substituted **anywhere** within the resource template.
+`TriggerTemplate`s have [parameters](#parameters) that can be substituted **anywhere**
+within the resource template.
 
 <!-- FILE: examples/triggertemplates/triggertemplate.yaml -->
 ```YAML
@@ -15,6 +16,9 @@ spec:
       default: master
     - name: gitrepositoryurl
       description: The git repository url
+    - name: message
+      description: The message to print
+      default: This is the default message
   resourcetemplates:
     - apiVersion: tekton.dev/v1alpha1
       kind: PipelineResource
@@ -40,14 +44,17 @@ spec:
       spec:
         pipelineRef:
             name: simple-pipeline
+        params:
+        - name: message
+          value: $(params.message)
         resources:
         - name: git-source
           resourceRef:
             name: git-source-$(uid)
 ```
 
 Similar to [Pipelines](https://github.com/tektoncd/pipeline/blob/master/docs/pipelines.md),`TriggerTemplate`s do not do any actual work, but instead act as the blueprint for what resources should be created.
-Any parameters defined in the [`TriggerBinding`](triggerbindings.md) are passed into to the `TriggerTemplate` before resource creation.
+
 If the namespace is omitted, it will be resolved to the `EventListener`'s namespace.
 
 The `$(uid)` variable is implicitly available throughout a `TriggerTemplate`'s resource templates.
@@ -56,6 +63,20 @@ One instance where there is useful is when resources in a `TriggerTemplate` have
 
 When creating resource, an additional label is added on created resources with the following value: `event-listener-name`: `<EventListenerName>`.
 Mark all resources created by a certain EventListener, which helps with housekeeping.
- 
+
 To enable support for any resource type, the resource templates are internally resolved as byte blobs.
 As a result, validation on these resources is only done at event processing time (rather than during `TriggerTemplate` creation).
+
+## Parameters
+`TriggerTemplate`s can declare parameters that are supplied by a
+`TriggerBinding`. `params` must have a `name`, and can have an optional
+`description` and `default` value.
+
+`params` can be referenced in the `TriggerTemplate` using the following
+variable substitution syntax, where `<name>` is the name of the parameter:
+```YAML
+$(params.<name>)
+```
+`params` can be referenced in the `resourceTemplates` section of a
+`TriggerTemplate`. The purpose of `params` is to make `TriggerTemplates`
+reusable.

examples/README.md

@@ -18,7 +18,7 @@ kubectl apply -f eventlisteners/eventlistener.yaml
 ```bash
 tekton:examples user$ kubectl get svc
 NAME                          TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
-listener                      LoadBalancer   10.100.151.220   localhost     8082:30607/TCP   48s  <--- this will receive the event
+listener                      ClusterIP      10.100.151.220   <none>        8082/TCP         48s  <--- this will receive the event
 tekton-pipelines-controller   ClusterIP      10.103.144.96    <none>        9090/TCP         8m34s
 tekton-pipelines-webhook      ClusterIP      10.96.198.4      <none>        443/TCP          8m34s
 tekton-triggers-controller    ClusterIP      10.102.221.96    <none>        9090/TCP         7m56s
@@ -37,7 +37,9 @@ tekton-triggers-webhook-5985cfcfc5-cq5hp       1/1       Running   0          6m
 
 3. Apply an example pipeline and tasks that will be run (in this case named `simple-pipeline`):
 
-`kubectl apply -f example-pipeline.yaml`
+```bash
+kubectl apply -f example-pipeline.yaml
+```
 
 This is intentionally very simple and operates on a created Git resource. The trigger created Git resource will have the repository URL and revision parameters.
 
@@ -53,8 +55,8 @@ curl -X POST \
 	"head_commit":
 	{
 		"id": "master"
-	}, 
-	"repository": 
+	},
+	"repository":
 	{
 		"url": "https://github.com/tektoncd/triggers.git"
 	}
@@ -72,7 +74,7 @@ git-source-g8j7r   1s
 ```bash
 tekton:examples user$ kubectl get pipelinerun
 NAME                       SUCCEEDED   REASON    STARTTIME   COMPLETIONTIME
-simple-pipeline-runxl8rm   Unknown     Running   1s      
+simple-pipeline-runxl8rm   Unknown     Running   1s
 ```
 
 ```bash
@@ -116,6 +118,9 @@ spec:
   - name: git-source
     resourceRef:
       name: git-source-g8j7r
+  params:
+  - name: message
+    value: Hello from the Triggers EventListener!
   serviceAccount: ""
   timeout: 1h0m0s
 status:
@@ -129,14 +134,20 @@ status:
   ...
 ```
 
-3. The two Pods (one per Task) finish their work and the PipelineRun is marked as successful:
+3. The three Pods (one per Task) finish their work and the PipelineRun is marked as successful:
 
 ```
 tekton:examples user$ kubectl logs simple-pipeline-runn4qps-say-hello-29ztk-pod-118fbd --all-containers
 ...
 Hello Triggers!
 ```
 
+```
+tekton:examples user$ kubectl logs simple-pipeline-runn4qps-say-message-f64qf-pod-80fb58 --all-containers
+...
+Hello from the Triggers EventListener!
+```
+
 ```
 tekton:examples user$ kubectl logs simple-pipeline-runn4qps-say-bye-7xbk2-pod-116608  --all-containers
 ...

examples/eventlisteners/eventlistener.yaml

@@ -7,5 +7,8 @@ spec:
   triggers:
     - binding:
         name: pipeline-binding
+        params:
+          - name: message
+            value: Hello from the Triggers EventListener!
       template:
         name: pipeline-template