Further to #47 and as per the .pdf sketch linked in #37, clicking on a webhook name in the list of webhooks should take the user to a list of branches in the associated git repository. This will need additional support from the REST API to retrieve this list - we might as well get the list of branches from git, rather than by scraping them from all the pipelineruns we might have.

(There's the possibility of some branches existing but having no builds, and of builds existing whose branches have been deleted. That could be a problem but we're deferring it for now.)

Like for the dashboard we should automatically run a linter for every PR. Note that whoever picks this up should fix the linter issues first; else this PR is never going to go green!

https://github.com/tektoncd/dashboard/search?utf8=%E2%9C%93&q=lint&type= is an excellent place to start.

@iancoffey
I saw the Getting start doc.
Firstly, I like the project, seems it's depends on Knative event-sources (Am I right?), so it could support all sources from Knative-sources, such as github, kafka .etc. that's great.

I still have some question need clarification, thanks

1. No event binding in EventBinding crd.
   I have not see any event binding, like things: ${event.foo}, just some environment variables: $GHREPO, I think this could come from the content of event.

2. The TektonListener , seems this crd will created by EventBinding? if not any event binding requirement, just trigger. Could TectonListener be created independent?

3. Based on the process diagram, seems the PipelineResource will be create by EventBinding.
   That's not make sense, at the time, the event still not emitted, so no event could binding to PipelineResource, am I right? so I'm little confuse here, do we just create a PipelineResource template or what?

Expect to your reply, thanks.

Additional Info

See slide 9 in this presentation by @dibbles. :
Extension.pdf

Currently we build commits on any branch but end up with a jumble of pipeline runs sorted at best by date. We need to be able to filter pipeline runs by repository and then further, optionally, by branch. @mnuttall talked to @skaegi about this at the end of May. We agreed that applying labels to PipelineRuns and then filtering by those labels is the correct design.

• #47 Add 'Repo' and 'Branch' filters to PipelineRuns
• #48 Clicking webhook name in webhooks collection takes user to a list of branches (all branches) in the repo
• #49 Clicking branch name takes user to a view of filtered pipeline runs
• #50 Display latest status in 'branches' collection - build status and time columns
• #51 Display the settings collected when creating hook, on hook details tab

tektoncd/pipeline#895 is getting close to being merged. It introduces a first level of support for a PullRequest PipelineResource. Use this issue to build a working prototype in which a pipeline run created by a webhook from an incoming Pull Request from a github fork results in the associated pull request being updated. We want to know:

• Can we access the 'status' of the pull request to reflect whether the build was successful or not?
• If not what can we currently do? Add comments? What else?

Our current sink code will need to be updated so as to create a PullRequest pipeline resource. Obviously the code is not merged yet so things may be a bit flaky!

Update Epic #36 with more tasks once we better understand where we're starting.

the design doc states,

An author of a Tekton Task should be able to write a Task which takes an SCM PipelineResource as an:

Input: This should make data about an existing Pull Request available to a Task, including:

• Description
• Corresponding version control info (HEAD commit/ref/repo, base commit/ref/repo)
• Comments
• Check status(es)

Output: After Task execution, changes made to the PipelineResource should be reflected in the
Pull Request including:

• Comments
• Check status(es)
• Merging the pull request/closing issues.
• Label manipulation
• Description edits

Which of these have been implemented so far under tektoncd/pipeline#895? Which if any are under development?

The 'first pass' at panelling for webhook management allows for access tokens to be created and deleted. We need a separate 'access token management' page where existing tokens can be presented in tabular form, as well as created and deleted. (Edit is not required.)

Consider whether users creating webhooks can be linked to and from a unified access token management dialog when creating one in the process of creating a webhook.

One could argue that the webhooks extension should only show items in the table that are in the selected namespace from the dropdown of the main dashboard (left hand menu).

Expected Behavior

The delete webhooks pop up toolbar menu that shows when selecting webhoooks in the table should disappear if the webhooks are successfully deleted.

Actual Behavior

After the webhook is deleted, the menu is still active and showing "0 selected"

Steps to Reproduce the Problem

1. create some webhooks
2. select one in the table
3. click delete and confirm
4. the blue deletion menu bar is still visible and notification states webhooks deleted

The webhooks creation form currently checks that all fields are complete before enabling the Create button - this is inconsistent with other pages in the main dashboard which validate on submission and highlight the incorrect fields red boxes.

In addition to checking that the field is not empty we should...

Validate display name chars ?
Validate URL entry ?
Validate docker registry field ?

This modification to the way we do validation should also be made in the access token secret creation modal.

Success and error notifications seem to be missing close buttons on the webhooks UI.

When creating an access token secret in the create webhook UI, the secret is not then shown as selected in the drop down upon success. I would expect after successful creation, that it is shown as the selected item.

Access tokens are required to manage git webhooks. Access tokens can be created and deleted via the 'create webhook' wizard but a more general 'access token management' page is required.

This issue leads on from #53 which asks two issues needing design input:

• What's the navigation path to the access token management page?
• Can a single 'create access token' dialog be reused between 'create webhook' and 'access token management?'

Having resolved those questions, use this issue to implement an 'access token management' page that lets users,

• List access tokens
• Create access tokens, both while creating a web hook and standalone, and
• Delete access tokens

Build state should be reflected in Pull Requests that have been triggered by webhooks.

Much of the relevant work is being done within the pipelines repo. See the design doc https://docs.google.com/document/d/1MXy-AOZmrgNusX710MgeERin_RkjNhnl0P5e5-ROhuc/edit#heading=h.7lbf68d7v887 which is linked from tektoncd/pipeline#778

See also tektoncd/pipeline#895

Like we do for the dashboard and pipeline repositories, we need to be able to build and test PRs automatically for code added into the webhooks-extension folder.

This includes running the Go tests and web tests when we eventually add them.

A good place to start is to look at the code here and here.

Further to #52 we need a clear and simple guide for how to set up webhooks via the dashboard webhooks-extension. This needs to cover:

• Importing pipeline definitions
• Create git and docker hub secrets for use in a pipeline
• Create a webhook, and in the course of that create an access token which will be used to create the webhook
• Create a simple demo application that can be used in the course of the guide.
• Update https://github.com/tektoncd/experimental/tree/master/webhooks-extension/test as necessary

GitLab is a popular source control system that many users will wish to integrate with Tekton via webhooks. We currently use the Knative GitHub Event Source which does not support GitLab. This issue is part of Epic #42 which is ranked lower than Epic #40, 'Stop using Knative for webhooks.' Ideally #40 should be progressed before this issue - in particular, we need a clear design for

• how we expect to register webhooks
• how we expect to receive them
• how we expect to trigger pipeline and taskruns as a result

This issue should focus on the GitLab-specific work that must be performed in all cases:

• Is there a functional Golang library that we can use to register webhooks against GitLab?
• What forms of credentials are best used?
• Are the GibLab APIs consistent between the hosted and locally installed versions?

User this issue, develop a working prototype that:

• Registers a webhook against a locally installed GitLab server
• Triggers a PipelineRun as a result of a git push

The webhooks extension user interface needs looking over for a11y issues and any fixes needed should be made.

When creating a credential using the webhooks extension the API uses:

POST /webhooks/credentials?namespace=x
{
  "name": "my-access-token",
  "accesstoken": "ksdufbliubsliuvbsliucbsiucslicbsh98wehr8w9huwbcwb87ec"
}

This is inconsistent with create webhook and general practice, where the namespace would be included in the body of the post, not as a query parameter.

When all fields are complete the create button jumps to the left due to incorrect css refactoring sharing the cancel buttons css.

When creating a new access token secret via the UI, the icon for showing/hiding the access token characters actually sits over the text entered - thus if you enter something really long the last couple of chars can disappear behind the icon - this shouldn't happen.

Additionally, the icon is not fully inside the text entry box and sometimes when the box is selected the blue lines cut through the icon(s).

It's currently non-trivial to install the extension following our instructions. Under this issue, rework the main README.md with a view to making it easy to install and use the extension if you're just a consumer and not somebody wishing to develop it or extend it.

As both of the experimental projects address the same core problem, triggering pipelineRuns, it makes sense to coalesce into one code base.

In the current form of the webhooks-extension code, RESTful endpoints use internal representations/structs and config-maps to stand as a (less than ideal) pipelineRun templating solution. Although heavily constrained, for the use case it does generate pipelineResources at event time as well as the corresponding pipelineRun.

The tekton-listener code/subrepo solely addresses triggering (not templating) through K8s CRDs and controllers. When an eventBinding custom resource is created, the controller creates all the pipelineResources specified in the spec and then create a tektonListener, which has a pod waiting for events. When an event in received, a pipelineRun is created as specified in the tektonListener's pipelineRunSpec.

The tekton-listener abstraction is an improvement over the webhooks-extension approach since CRDs are used rather than internal structures and config-maps. Furthermore, CRD controllers provide a more K8s native approach (which is in-line with Tekton) than the webhooks-extension server approach. However, the tekton-listener eventing mechanism does not have any templating support. So, we cannot create a pipelineResource using event data.

At the moment, the tekton-listener code cannot be used by the webhooks-extension because the tekton-listener lacks templating for pipelineRuns/pipelineResources. In order to merge both projects, we need to discuss the situation and come to some solution.

The Add button on the main display table is not the cleanest/prettiest design going, replace with something more stylish - perhaps just an icon.

Further to 03eeb7c we see this in webhooks-extension/config/sink-kservice.yaml:

# TODO: Find better way to provide INSTALL_NAMESPACE since Knative does not support Downward API
  - name: INSTALLED_NAMESPACE
    value: "default"

This prevents webhooks from working in non-default namespaces unless one edits that file, which is less than ideal. Is there any way around this in Knative Serving yet? We want to extract ourselves from Knative so don't want to a lot of work in Knative to fix or work around this, we'd definitely like to support non-default namespaces if at all possible.

Expected Behavior

package-lock.json should be adhered to

Actual Behavior

We suggest npm installing. We should suggest Node.js 10.x I believe and npm ci instead so our package-lock.json is taken into account.

@dibbles noticed bold font styling and a scrollbar on the delete dialog for the extension when using Node 12 with a newly generated package-lock.json as a result of npm installing - by using npm ci with both the dashboard and extension, we're good.

See tektoncd/dashboard#277 for the related dashboard issue.

The webhook creation UI seems to be a bit random when it comes to using the tab key to navigate around the page.... we should flow in a logical manner across the fields (this might have been looked at under the a11y issue #63)

Webhooks are the first 'event' we've used to trigger PipelineRuns. This Epic covers our expanding to support 'docker push' as a means to initiate a Tekton PipelineRun.

'Docker push' targets to support include,

• OpenShift - "OpenShift Container Platform provides an internal, integrated Docker registry that can be deployed in your OpenShift Container Platform environment to locally manage images"
• Docker Hub
• Artifactory
• gke?

See Epic #40 'Stop using Knative' - the expectation is that we'd wean the webhooks-extension off Knative before adding new types of trigger events.

If a repository URL is entered that ends with .git, the pipelinerun is not created fro the webhook trigger - this is because a lookup is done on the repourl without the .git.

We need to work with and without .git being entered.

Expected Behavior

We should have consistency e.g. modal fading background behaviour, text alignments, and the modal appearance and colours used (e.g. for the delete webhook modal and for the create access token modal).

Actual Behavior

vs

Steps to Reproduce the Problem

Install the extension, try to create a webhook and then try to delete a webhook.

Expected Behavior

We'd like a white background with a simple blue tick as opposed to a blue background and a white tick.

Actual Behavior

Steps to Reproduce the Problem

1. Install the extension
2. Create a webhook
3. Click to delete a webhook and see the odd styling

The changes should be made in https://github.com/tektoncd/experimental/blob/master/webhooks-extension/src/components/WebhookDisplayTable/StyledCheckbox.js

Currently we can only create webhooks for GitHub. GitLab is a widely used alternative that we should support.

Note that Epic #40 would remove our use of the Knative GitHub Event Source. The implementation work under this epic needs to take that done, or planned, under 40 into account.

The initial webhooks implementation used the Knative and the Knative GitHub Event Source to:

• Create and delete GitHub webhooks
• Expose an external endpoint via ksvc/Ingress for the GitHub webhooks to be delivered to
• Deliver webhook payloads to the webhooks 'sink' code for processing

The Knative dependency resulted in 'webhooks' being implemented as a dashboard extension rather than as core dashboard capability. It also complicates the installation process. Remove our Knative dependency by:

• Extending the Dashboard install operator to include an Ingress endpoint for webhook delivery
• Use Go libraries directly to register and delete webhooks
• See #39: webhooks should cause PipelineRun creation through the Tekton Events code: can this function in the absence of Knative? Find out !

See also tektoncd/dashboard#212 - we need to know how we're going to handle Ingress as part of this work.

I'm creating this issue following the TektonListener and EventBinding code being merged into the experimental repo in the tekton-listener directory. These two CRDs add great value for eventing with Tekton, but I think they can be refactored to improve their usability.

Sorry in advance for my long-winded explanations 😄

Why I think the CRDs should be refactored

My concerns with the current TektonListener & EventBinding CRDs (documented here) are as follows:

1. The TektonListener andEventBinding store overlapping information about PipelineRuns.

First, both CRDs store the same pipelineRef field. Also, the TektonListener stores an entire PipelineRunSpec, but the EventBinding also stores the params for the PipelineRunSpec. There is a weird division where the TektonListener owns the PipelineRun information, and the EventBinding owns the PipelineResource information; however, the EventBinding creates the TektonListener, so the EventBinding must also own some of the PipelineRun information which it uses to create the TektonListener. This ownership division is confusing to me, and I think that one of the CRDs should own all of the PipelineRun information.

2. The TektonListener and EventBinding store overlapping information about eventing.

This is similar to my previous concern about ownership of information. The EventBinding has an EventRef field with an EventName and EventType. This same information is also stored in the TektonListener as its Event and EventType fields. Again, this ownership division is confusing to me, and I think that one of the CRDs should own all of the eventing information.

3. The TektonListener and EventBindings store reusable information that cannot be reused

Together, the TektonListener and EventBinding store the entire configuration of a Pipeline Execution: a PipelineRun with its necessary PipelineResources. I think that this "Pipeline Execution" information should be reusable for different types of events. However, as I wrote in my previous two points, the current configuration stores overlapping PipelineRun and eventing information in both the TektonListener and EventBinding CRDs. So, neither of these CRDs can be reused.

For example, if a user has a working TektonListener and EventBinding setup for GitHub pull_request events, and now wants to use the same Pipeline with a different repository and GitLab push events, the user will need to create new TektonListener and EventBinding CRDs. Even though the "Pipeline Execution" configuration of PipelineRun and PipelineResources will be the same for these two new CRDs, the user will not be able to reuse either of the CRDs.

4. PipelineRuns cannot use information from the event as parameters

PipelineRuns are not included in the EventBinding template section, so their parameters cannot store information from the event.

Proposal for refactoring the CRDs

My primary motivation with refactoring the CRDs is to separate the eventing information from the Pipeline Execution information, and to keep the core functionality that @iancoffey introduced intact. The following is an example of a simple Pipeline Execution triggered by a GitHub push event, using my refactored CRDs named TemplateBinding and Template (the names as well as the designs are open to discussion):

apiVersion: tekton.dev/v1alpha1
kind: TemplateBinding
metadata:
  name: simple-pipeline-push
  namespace: default
spec:
  templateRef:
    name: simple-pipeline-template
  serviceAccount: default
  event:
    class: cloudevent
    type: com.github.push
  params:
    - name: gitrevision
      value: ${event.head_commit.id}
    - name: gitrepositoryurl
      value: ${event.repository.url}
    - name: dockerusername
      value: ncskier
    - name: dockerappname
      value: helloworldapp

apiVersion: tekton.dev/v1alpha1
kind: Template
metadata:
  name: simple-pipeline-template
  namespace: default
spec:
  params:
    - name: gitrevision
      description: git revision
      default: master
    - name: gitrepositoryurl
      description: git repository url
    - name: dockerusername
      description: docker username
    - name: dockerappname
      description: docker app name
  templates:
    - kind: PipelineResource
      metadata:
        name: docker-image
      spec:
        type: image
        params:
        - name: url
          value: "docker.io/${params.dockerusername}/${params.dockerappname}"
    - kind: PipelineResource
      metadata:
        name: git-source
      spec:
        type: git
        params:
        - name: revision
          value: ${params.gitrevision}
        - name: url
          value: ${params.gitrepositoryurl}
    - kind: PipelineRun
      metadata:
        name: simple-pipeline-run
      spec:
        pipelineRef:
            name: simple-pipeline
        trigger:
          type: event
        resources:
        - name: git-source
          resourceRef:
            name: git-source
        - name: docker-image
          resourceRef:
            name: docker-image

Similar to the TektonListener CRD, each TemplateBinding CRD would create its own event listener.

Improvements

Here is how the proposed refactor addresses my previous concerns:

1. The TektonListener andEventBinding store overlapping information about PipelineRuns.

The Template owns all the information about PipelineRuns, aside from some parameters that it exposes to the TemplateBinding.

2. The TektonListener and EventBinding store overlapping information about eventing.

The TemplateBinding owns all the information about eventing.

3. The TektonListener and EventBindings store reusable information that cannot be reused

The Template stores the Pipeline Execution information that can be reused by any number of TemplateBindings. This will be especially useful when you want to create a Pipeline definition, because your Pipeline can support any type of eventing by providing a Template file along with your Pipeline and Task YAML files.

For example, if a user has a working Template and TemplateBinding setup for GitHub pull_request events, and now wants to use the same Pipeline with a different repository and GitLab push events, the user will only need to create one new TemplateBinding CRD.

4. PipelineRuns cannot use information from the event as parameters

The Template can expose a parameter used in the PipelineRun template, and the TemplateBinding can populate this parameter with information from the event.

Feedback

Please let me know what you think about this refactor proposal 🙂
@iancoffey @dlorenc

Just like we do for the dashboard we should also run npm install and npm test for now.

For reference see #59 for what was done for running Go tests.

I'm going to make a new issue for linting as well as we'll want that for sure (again like we do for the dashboard). I'm cool with npm install and npm test only for now.

Expected Behavior

We want to build and push the webhook extension images in to public repository like gcr.io or dockerhub when the code is merged into master. These images will be available for testing, experimenting and use.

Actual Behavior

No docker images are built. No images are published.

This issue is part of experimental epic #37 but concerns development changes in dashboard. The webhooks extension needs to be able to filter pipeline runs by repository and branch: it makes sense to surface this capability to dashboard users.

Under Dashboard > PipelineRuns, users should be able to filter the pipeline runs shown by 'git repository' and 'branch'. These can be passed as query params to the /pipelineruns REST API. We should apply labels to pipeline runs so as to be able to filter by these labels when obtaining pipeline runs via the Go client.

Expected Behavior

npm test should pass, then we can get into the automated testing runs

Actual Behavior

See

    TypeError: _this.props.setShowNotificationOnTable is not a function

      18 |     super(props);
      19 |     // turn off webhook created message
    > 20 |     this.props.setShowNotificationOnTable(false);
         |                ^

Steps to Reproduce the Problem

1. npm install
2. npm test

Additional Info

Actual code, jest config or babel related I reckon!

As per Epic #38,

The 'first pass' at panelling for webhook management allows for access tokens to be created and deleted. We need a separate 'access token management' page where existing tokens can be presented in tabular form, as well as created and deleted. (Edit is not required.)

Consider whether users creating webhooks can be linked to and from a unified access token management dialog when creating one in the process of creating a webhook.

Key issues to resolve:

• What's the navigation path to the access token management page?
• Given the restrictions imposed by the 'extension' architecture, can the 'create webhook' panelling be refactored so as to pass 'create access token' to a unified 'create' panel? Or is the current 'pop up' panel ok as it is?

I had doubts immediately on raising this issue. DockerHub is only a useful source of trigger events if they can be routed to a given Tekton instance. I'm going to put this in the Icebox until we've a clearly identified need to implement this support.

Expected Behavior

controller and tekton-listener containers are built successfully using ko and pushed to local Docker repository

Actual Behavior

Container fails to build with compilation errors

Steps to Reproduce the Problem

Set up minikube locally and try to run ko:

$ ko apply -L -f config/
2019/05/07 15:43:17 Building github.com/tektoncd/experimental/tekton-listener/cmd/tekton-listener
2019/05/07 15:43:17 Building github.com/tektoncd/experimental/tekton-listener/cmd/controller
2019/05/07 15:43:17 Building github.com/tektoncd/pipeline/cmd/kubeconfigwriter
clusterrolebinding.rbac.authorization.k8s.io/tekton-experimental-controller-admin created
clusterrole.rbac.authorization.k8s.io/tekton-experimental-admin created
customresourcedefinition.apiextensions.k8s.io/eventbindings.tekton.dev created
customresourcedefinition.apiextensions.k8s.io/tektonlisteners.tekton.dev created
2019/05/07 15:43:18 Unexpected error running "go build": exit status 2
# github.com/tektoncd/experimental/tekton-listener/cmd/tekton-listener
../../../go/src/github.com/tektoncd/experimental/tekton-listener/cmd/tekton-listener/main.go:77:55: cannot use clientcfg (type *"k8s.io/client-go/rest".Config) as type *"github.com/tektoncd/pipeline/vendor/k8s.io/client-go/rest".Config in argument to "github.com/tektoncd/pipeline/pkg/client/clientset/versioned".NewForConfig
../../../go/src/github.com/tektoncd/experimental/tekton-listener/cmd/tekton-listener/main.go:181:3: cannot use "k8s.io/apimachinery/pkg/apis/meta/v1".ObjectMeta literal (type "k8s.io/apimachinery/pkg/apis/meta/v1".ObjectMeta) as type "github.com/tektoncd/pipeline/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".ObjectMeta in field value
2019/05/07 15:43:18 Unexpected error running "go build": exit status 2
# github.com/tektoncd/experimental/tekton-listener/pkg/reconciler/tektonlistener
../../../go/src/github.com/tektoncd/experimental/tekton-listener/pkg/reconciler/tektonlistener/reconciler.go:76:3: cannot use logger (type *"github.com/tektoncd/pipeline/vendor/go.uber.org/zap".SugaredLogger) as type *"go.uber.org/zap".SugaredLogger in field value
../../../go/src/github.com/tektoncd/experimental/tekton-listener/pkg/reconciler/tektonlistener/reconciler.go:78:28: cannot use logger (type *"github.com/tektoncd/pipeline/vendor/go.uber.org/zap".SugaredLogger) as type *"github.com/knative/pkg/vendor/go.uber.org/zap".SugaredLogger in argument to controller.NewImpl
# github.com/tektoncd/experimental/tekton-listener/pkg/reconciler/eventbinding
../../../go/src/github.com/tektoncd/experimental/tekton-listener/pkg/reconciler/eventbinding/reconciler.go:80:3: cannot use logger (type *"github.com/tektoncd/pipeline/vendor/go.uber.org/zap".SugaredLogger) as type *"go.uber.org/zap".SugaredLogger in field value
../../../go/src/github.com/tektoncd/experimental/tekton-listener/pkg/reconciler/eventbinding/reconciler.go:82:28: cannot use logger (type *"github.com/tektoncd/pipeline/vendor/go.uber.org/zap".SugaredLogger) as type *"github.com/knative/pkg/vendor/go.uber.org/zap".SugaredLogger in argument to controller.NewImpl
../../../go/src/github.com/tektoncd/experimental/tekton-listener/pkg/reconciler/eventbinding/reconciler.go:139:124: cannot use "k8s.io/apimachinery/pkg/apis/meta/v1".GetOptions literal (type "k8s.io/apimachinery/pkg/apis/meta/v1".GetOptions) as type "github.com/tektoncd/pipeline/vendor/k8s.io/apimachinery/pkg/apis/meta/v1".GetOptions in argument to c.Base.PipelineClientSet.TektonV1alpha1().PipelineResources(resource.ObjectMeta.Namespace).Get
2019/05/07 15:43:20 Using base gcr.io/distroless/static:latest for github.com/tektoncd/pipeline/cmd/kubeconfigwriter
2019/05/07 15:43:21 Loading ko.local/kubeconfigwriter-3d37fea0b053ea82d66b7c0bae03dcb0:2b3ff3191d94900c4f7e15583090bf859f09a38d2805db363141728637c4f48b
2019/05/07 15:43:23 Loaded ko.local/kubeconfigwriter-3d37fea0b053ea82d66b7c0bae03dcb0:2b3ff3191d94900c4f7e15583090bf859f09a38d2805db363141728637c4f48b
2019/05/07 15:43:23 Adding tag latest
2019/05/07 15:43:23 Added tag latest
2019/05/07 15:43:23 error processing import paths in "config/controller.yaml": exit status 2

This can also be reproduced in a clean environment using this minimal Dockerfile:

FROM golang:1.11

ENV GOPATH /go
RUN mkdir -p /go && \
    go get -u github.com/tektoncd/experimental/tekton-listener/cmd/controller

CMD ["controller"]

Expected Behavior

The checkbox button should reset for deleting PipelineRuns. We should have a test for this too. Could be as simple as, when we display the dialog, setting the state of the checkbox to be unchecked, and then add a test for it.

Actual Behavior

It's not reset to be unchecked on modal entry for the delete dialog.

Steps to Reproduce the Problem

1. Install the webhooks extension
2. Create a webhook
3. When deleting a webhook on the modal, click to delete PipelineRuns: the box is checked
4. Close the modal
5. Try to delete a webhook again and observe the button is still checked

See tektoncd/dashboard#47 - this issue and dashboard 47 are very closely linked, and are probably duplicates.

Webhooks creation and manual pipeline run initiation are much too hardcoded for a small subset of test pipelines. We need a much more flexible design in both areas. Ideally:

• replace our 'sink' code with the EventBinding/TektonListener experimental engine
• See #19 - specifically @ncskier's proposed

apiVersion: tekton.dev/v1alpha1
kind: TemplateBinding
metadata:
  name: simple-pipeline-push
  namespace: default
spec:
  templateRef:
    name: simple-pipeline-template
  serviceAccount: default
  event:
    class: cloudevent
    type: com.github.push
  params:
    - name: gitrevision
      value: ${event.head_commit.id}
    - name: gitrepositoryurl
      value: ${event.repository.url}
    - name: dockerusername
      value: ncskier
    - name: dockerappname
      value: helloworldapp

This TemplateBinding format gives us a way of defining the parameters that we should attempt to automatically fill in - gitrevision, gitrepositoryurl, and those params that the user must provide - docker username, application name.

We should make every effort to move the Tekton EventBinding integration work forward as a pre-req to this work.

Expected Behavior

The Webhooks experimental unit tests pass reliably.

Actual Behavior

TestCreateDeleteCorrectData has been seen to be failing in the unit tests, I have seen two successive failures on my PR which report:

webhook_test.go:722: Iteration 74, didn't delete the first webhook OK for the safe multiple request creation and deletion test, response: 404
webhook_test.go:738: For iteration 74 we found routine1createhook-74 when it should have been deleted

Additional Info

See https://tekton-releases.appspot.com/build/tekton-prow/pr-logs/pull/tektoncd_experimental/78/pull-tekton-experimental-unit-tests/1140614579961729024/ & https://tekton-releases.appspot.com/build/tekton-prow/pr-logs/pull/tektoncd_experimental/78/pull-tekton-experimental-unit-tests/1140610050532839424/

This issue is part of Epic #41: 'docker push' as a trigger for Tekton pipelines. In this case, we want to know what it will take to trigger Tekton pipelines as a result of operations on the OpenShift Container Platform container registry. As a preliminary investigation we need to know:

• Does the OCP container registry offer an external API?
• Does it support webhooks? What if any events can be subscribed to?

We don't want to have to poll the registry if there's any way to receive notifications or events from it. We are particularly interested in knowing:

• can we get events or must we poll?
• the names of pushed images
• the tags of pushed images
• the labels on pushed images (from LABEL commands in Dockerfiles)
• what if any other metadata is available
• what credentials must be provided, and how, in order to use the container registry APIs

As a webhooks-extension user I want to set up one webhook to trigger the Red pipeline in the red-team namespace and another hook to trigger the Green pipeline in the green-team namespace.

There may be other cross- or multi-namespace issues that should become clearer while working on this one.

See also 'all namespaces' support in the dashboard, tektoncd/dashboard#166

We expect Tekton to be deployed into operational environments that are deliberately restricted from reaching out to the Internet. Webhooks still need to be configured and piplelines to run.

Set up, test, document and rework such that we can demonstrate webhooks and pipelines working for:

• No internet access

• GitLab - source code, pipeline definitions

• Maven repository in Nexus - Java projects

• Node projects: offline npm repository. (Nexus?)

• OpenShift docker registry

• Artifactory as an alternative docker registry

• Go projects: can dep ensure work offline? Do all dependencies need to be checked in instead? Can developers even write Go at all if they cannot reach out to the Internet?

• Another flavour allows HTTP proxies, which must be used to gain external access.

When the webhooks table is loading a spinner indicates the page is loading, one could reasonably argue that this should instead be rendering the page but with a carbon component table skeleton.

http://react.carbondesignsystem.com/?selectedKind=DataTableSkeleton&selectedStory=default&full=0&addons=1&stories=1&panelRight=0&addonPanel=storybook%2Factions%2Factions-panel