# Tekton as a Code

## What is it

As stated upstream [here](https://github.com/tektoncd/pipeline/issues/859)

It should be possible to define Pipeline and Task definitions and have them committed to a repo which they act on (e.g. this is the intent of the tekton dir in this repo!).

* Changes to these definitions that are committed to the repo should be picked up and used as soon as they are merged
* Changes to these definitions in pull requests should be used when testing the pull request, but without affecting any other Runs (e.g. already executing Runs, Runs executing against other Pull Requests)

## Typical scenario

### Github PR tested with a Pipeline CI
* User has setup a pipeline for the repository `project` to test and build code on each PR, it gets kicked via Trigger and the GitHub interceptor.
* The pipeline definitions sits in the `/tekton` directory at the top of the 'project' repository.
* User wants to modify its pipeline to add a yaml check task for example.
* User kicks off her/his $EDITOR and send a PR that add the yaml check task.
* Triggers pick up the webhook events and sees the `/tekton` change.
* Triggers start a new pipeline called `apply-pr` with argument *pr=12345*.
* The `apply-pr` pipeline creates a new ns/project called `pr-12345`
* The `apply-pr` apply the new pipeline to that namespace if that fails it will report back on Github PR
* It will then kicks off a `PipelineRun` according to what we have we had in the triggerbinding definition. (is that possible??).
* We would need to find a way to report back the success/fails of the task with a final task.

#### Others? Should we handle other scenarios for tekton?

## Issues

* How do we know where to apply the pull request, i.e: on which namespace.
* Can we rely on `kubectl apply` for detecting object changes?
* How do we make sure that the tested pull request can be reverted if not merged.
* Do we handle the use case where there is other resources that may be dependent of the pipeline (i.e: a deployment) but not specified in the tekton directory.
* How do we handle deletions.
* How can we report back that the applied pipeline has been successfully deployed post merge.
* Are we reinventings something like argocd directly in tekton?
* Do we want a custom event interceptors service or handle everything directly with CEL/Ghub interceptors...

# Meeting Notes

* Questions ?
* Are we targetting gitops ?
* (vincent) I don't think so
* Initial target is "CI"
* so that we don't end up re-inventing Argo (that does bi-directionnal stuff, …)
* Could the "apply PR" be check and "done" through an interceptor ?
* (vincent) otherwise it needs a "specific" set of triggerbinding/triggertemplate
e.g. one pipeline that does the normal stuff (and doesn't get trigger in changes in `tekton/`)
and one pipeline that does the "apply pr" and the rest of the pipeline (triggers when there is changes in `tekton/`)
* UX: the benchmark is the GitHub Actions UX
1. User adds their pipelines and tasks in a certain structure inside the `.tekton` folder of the Git repository
2. User runs a command via `tkn` to add the git repo to cluster
3. The required configurations are done so that every commit to the git repo updates the Tekton resources on the cluster and triggers the pipeline
4. The Git commit updated github checks and the result of the pipeline run