Skip to content

Commit

Permalink
TEP-0032 Tekton notifications
Browse files Browse the repository at this point in the history
Add a TEP with motivation, a few use cases and high level stub
proposed solution in proposed state.

I also ran the hack/update-toc.sh tool.

Signed-off-by: Andrea Frittoli <[email protected]>
  • Loading branch information
afrittoli authored and tekton-robot committed Nov 30, 2020
1 parent b473795 commit 6822640
Show file tree
Hide file tree
Showing 6 changed files with 205 additions and 32 deletions.
6 changes: 3 additions & 3 deletions teps/0020-s390x-support.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,9 +15,9 @@ status: proposed
- [Goals](#goals)
- [Non-Goals](#non-goals)
- [Proposal](#proposal)
- [Design Details](#design-details)
- [Diagram for pipeline test with s390x hardware](#diagram-for-pipeline-test-with-s390x-hardware)
- [Risks and Mitigations](#risks-and-mitigations)
- [Design details](#design-details)
- [Diagram for pipelinetest with s390x hardware](#diagram-for-pipelinetest-with-s390x-hardware)
- [Risks and Mitigations](#risks-and-mitigations)
- [Test Plan](#test-plan)
- [References](#references)
<!-- /toc -->
Expand Down
49 changes: 24 additions & 25 deletions teps/0026-interceptor-plugins.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,31 +9,30 @@ status: implementable
# TEP-0026: Pluggable Interceptors

<!-- toc -->
- [TEP-0026: Pluggable Interceptors](#tep-0026-pluggable-interceptors)
- [Summary](#summary)
- [Motivation](#motivation)
- [Goals](#goals)
- [Non-Goals](#non-goals)
- [Requirements](#requirements)
- [Proposal](#proposal)
- [Notes/Constraints/Caveats](#notesconstraintscaveats)
- [Performance](#performance)
- [Design Details](#design-details)
- [HTTP Interface](#http-interface)
- [Request](#request)
- [Response](#response)
- [Example](#example)
- [Installing Interceptors](#installing-interceptors)
- [Using Interceptors in Triggers](#using-interceptors-in-triggers)
- [Alternatives](#alternatives)
- [Implement new HTTP interface without Interceptor CRD](#implement-new-http-interface-without-interceptor-crd)
- [Use go-plugin for built-in interceptors](#use-go-plugin-for-built-in-interceptors)
- [Allow operators to disable some built-in interceptors](#allow-operators-to-disable-some-built-in-interceptors)
- [Implement built-in interceptors using the current webhook interface](#implement-built-in-interceptors-using-the-current-webhook-interface)
- [Use a versioned Request/Response types to the HTTP API](#use-a-versioned-requestresponse-types-to-the-http-api)
- [Upgrade & Migration Strategy](#upgrade--migration-strategy)
- [Work Plan](#work-plan)
- [References](#references)
- [Summary](#summary)
- [Motivation](#motivation)
- [Goals](#goals)
- [Non-Goals](#non-goals)
- [Requirements](#requirements)
- [Proposal](#proposal)
- [Notes/Constraints/Caveats](#notesconstraintscaveats)
- [Performance](#performance)
- [Design Details](#design-details)
- [HTTP Interface](#http-interface)
- [Request](#request)
- [Response](#response)
- [Example](#example)
- [Installing Interceptors](#installing-interceptors)
- [Using Interceptors in Triggers](#using-interceptors-in-triggers)
- [Alternatives](#alternatives)
- [Implement new HTTP interface without Interceptor CRD](#implement-new-http-interface-without-interceptor-crd)
- [Use go-plugin for built-in interceptors](#use-go-plugin-for-built-in-interceptors)
- [Allow operators to disable some built-in interceptors](#allow-operators-to-disable-some-built-in-interceptors)
- [Implement built-in interceptors using the current webhook interface](#implement-built-in-interceptors-using-the-current-webhook-interface)
- [Use a versioned Request/Response types to the HTTP API](#use-a-versioned-requestresponse-types-to-the-http-api)
- [Upgrade &amp; Migration Strategy](#upgrade--migration-strategy)
- [Work Plan](#work-plan)
- [References](#references)
<!-- /toc -->

## Summary
Expand Down
6 changes: 3 additions & 3 deletions teps/0027-https-connection-to-triggers-eventlistener.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,9 +17,9 @@ status: implementable
- [Proposal](#proposal)
- [User Stories](#user-stories)
- [Usage examples](#usage-examples)
- [Design Details](#design-details)
- [Implementation Details](#implementation-details)
- [Upgrade &amp; Migration Strategy](#upgrade--migration-strategy)
- [Design Details](#design-details)
- [Implementation Details](#implementation-details)
- [Alternatives](#alternatives)
- [References](#references)
<!-- /toc -->

Expand Down
1 change: 0 additions & 1 deletion teps/0029-step-workspaces.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,6 @@ tags, and then generate with `hack/update-toc.sh`.
- [Summary](#summary)
- [Motivation](#motivation)
- [Goals](#goals)
- [Non-Goals](#non-goals)
- [Requirements](#requirements)
- [User Stories](#user-stories)
- [Story 1](#story-1)
Expand Down
174 changes: 174 additions & 0 deletions teps/0032-tekton-notifications.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,174 @@
---
status: proposed
title: Tekton Notifications
creation-date: '2020-11-18'
last-updated: '2020-11-18'
authors:
- '@afrittoli'
---

# TEP-0032: Tekton Notifications

<!-- toc -->
- [Summary](#summary)
- [Motivation](#motivation)
- [Goals](#goals)
- [Non-Goals](#non-goals)
- [Use Cases (optional)](#use-cases-optional)
- [Requirements](#requirements)
- [Proposal](#proposal)
- [User Experience (optional)](#user-experience-optional)
- [Alternatives](#alternatives)
- [References (optional)](#references-optional)
<!-- /toc -->

## Summary

This proposal seeks to provide "native notifications" in Tekton Pipelines:
notifications which are much more easily configurable than the existing
CloudEvents integration, can fire at important stages of a pipeline and task
lifecycle, and which allow users greater control over both the filtering of
resources / events that fire notifications as well as the types of notifications
that are sent.

Tekton users would highly benefit from native notification support in Tekton.

## Motivation

Tekton is a tool for building CI/CD systems. It allows automating workflows
using pipelines which may run autonomously most of the times, until something
goes wrong or they reach as step that require human involvement.

Notification can help raising the attention of an human being to a specific
workflow execution that is need of attention.

Several Tekton users ask about notifications in Tekton. We have developed two
features that may help implementing notifications:

- [Cloud events](https://tekton.dev/docs/pipelines/events/#events-via-cloudevents)
- [Finally](https://tekton.dev/docs/pipelines/pipelines/#adding-finally-to-the-pipeline)

Cloud events are triggered every time a pipeline or task is started, begins
executing and is terminated. Cloud events, combined with Tekton Triggers can
be used to execute tasks and pipelines as a reaction to an event. This is
used in our dogfooding cluster to generate notifications for failed CD pipelines.
It works fine, however it requires a good amount of YAML and plumbing resource
together to achieve the goal of notifications.

The "Finally" section in a pipeline allows execution tasks once all regular tasks
completed execution. Such "final" tasks can be used to send notifications about
the outcome of a pipeline, as they will always be invoked, even if a task in the
main pipeline failed. However final tasks are only executed at the end, so they
cannot be used for "start" notifications, and they are limited to pipelines.
Work is in progress to allow "final" tasks access to the execution status of tasks
in the main pipeline.

Tekton users would highly benefit from native notification support.

### Goals

The main goal of the TEP is to design and implement a notification system that
is both easy to use and flexible, for delivering notification targeted to humans.

Notifications are easy to use: enabling and configuring default notifications
to get something up and running (notifying on every event of every Pipeline/Task)
requires only few lines of configuration.

Notifications are flexible: users are able to configure the precise Pipelines/Tasks
and events that notifications are sent for. Users can also modify the configuration
for their chosen notification system.

A secondary goal is to make sure that notification can benefit from our growing
catalog of tasks, several of which have been written to deliver notification through
different platforms.

A third goal is to make notifications easier to troubleshoot and track.

### Non-Goals

- Build a machine to machine communication protocols
- Build pre/post execution hook for steps, tasks or pipelines
- Build a catalog of integration with different notification, chat or email systems
- Build a system to send large amounts of data produced by a task or pipeline
- Write a controller for cloud events (even if that could be part of the solution).
See [tektoncd/pipeline#2944](https://github.com/tektoncd/pipeline/issues/2944) for
further context.

### Use Cases (optional)

- Notify individuals or groups about the failure of a pipeline
- Notify individuals or groups about the completion of a long running task
- Notify individuals or groups about the start or a pipeline that was triggered as
a consequence of an automated event (cron, pull request, manual approval)

## Requirements

***This section is a stub and subject to change.***

Once notifications are implemented, we do not want to force Tekton users to modify
all their existing tasks or pipelines to enable notifications for them:

- Allow using catalog tasks as is
- Allow notifications for pipelines with no change to the pipeline itself

For installations that run large number of task and pipelines, the configuration
of notification should be designed to be scalable and easy to maintain.

- Allow selecting pipelines and tasks to be notified about via selectors
- Allow selecting events to be notified about
- Allow pipeline and task authors to re-use of notification "rules"

## Proposal

***This section is a stub and subject to change.***

The proposal is to introduce notification policies and templates.

Notification policies define condition under which we want to trigger a notification;
they would allow users to:

- filter sources such using rules (using CEL?)
- kind: task, pipeline
- metadata: name, labels, namespace, annotations(?)
- filter events such as start, run, success, fail (using CEL or syntax sugar on top)

Notification templates define how a notification is sent. They would allow user to:

- define the task / pipeline to be executed
- bind an event type with the inputs to the task / param

Both notification policies and templates could be defined a dedicated CRD.
The policy controller would be responsible to provision `trigger` resources by
combining the information from the policy and the templates.

Which notification template is triggered is decided based on runtime information passed to the `TaskRun`
or `PipelineRun`, or can be configured on Tekton for each namespace and added to resources
as an annotation.

All resources generated or associated with a notification policy and a notification
template will be automatically labelled by the notification controller so that they
can be easily identified and filtered.

### User Experience (optional)

Notification targeted to humans is the main goal of this TEP because I would like to make
sure that requirements for machine targeted notification do not pollute the user experience
of tekton native notifications.

User experience is very important for this proposal. Notification should be easy to use
and maintain across large number of tasks and pipelines.

## Alternatives

- Use cloud events + triggers and let user maintain the configuration and plumbing required
to fit everything together

## References (optional)

Additional context for this TEP can be found in the following issues:

- [Initial design document](https://docs.google.com/document/d/1ehhGngn2ulnjYX0HUxSyhQGAvcbabSa27UZs3RvZWwU/edit#heading=h.isehsedcrq00)
- [Actions and Notifications for Tekton](https://github.com/tektoncd/pipeline/issues/1740)
- [Move cloud events to a separate controller](https://github.com/tektoncd/pipeline/issues/2944)
- [Events on Tasks and Steps](https://github.com/tektoncd/pipeline/issues/742)
- [Alternative ways of running triggers](https://github.com/tektoncd/triggers/issues/504)
1 change: 1 addition & 0 deletions teps/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -144,3 +144,4 @@ This is the complete list of Tekton teps:
|[TEP-0029](0029-step-workspaces.md) | step-and-sidecar-workspaces | proposed | 2020-10-02 |
|[TEP-0030](0030-workspace-paths.md) | workspace-paths | proposed | 2020-10-18 |
|[TEP-0031](0031-tekton-bundles-cli.md) | tekton-bundles-cli | proposed | 2020-11-18 |
|[TEP-0032](0032-tekton-notifications.md) | Tekton Notifications | proposed | 2020-11-18 |

0 comments on commit 6822640

Please sign in to comment.