| status | title | creation-date | last-updated | authors | ||
|---|---|---|---|---|---|---|
proposed |
Polling runs in Tekton |
2021-09-13 |
2021-09-13 |
|
- Summary
- Motivation
- Requirements
- Proposal
- Questions
- Design Details
- Test Plan
- Design Evaluation
- Drawbacks
- Alternatives
- Infrastructure Needed (optional)
- Upgrade & Migration Strategy (optional)
- Implementation Pull request(s)
- References (optional)
This TEP introduces an idea for a feature in triggers which allows user to setup a poll which looks for changes on a repository and triggers pipelinerun/taskrun.
-
To allow users to use triggers without need to setup a webhook. Triggers could have a feature which allow user to setup a polling feature for a repository which would look for changes in repository and trigger a pipelinerun or taskrun.
This was briefly discussed on Issue #1168 and #480.
This can be solved currently by a setting up a cronjob to check for changes but having as a part of triggers could enhance triggers.
Both this feature and scheduled runs could be use cases of conditional triggering where one is at certain time and other would run at a certain time if an additional condition passes.
-
As a user, I don't have permission to setup a webhook on a repository having a polling feature could be helpful to solve this issue. I can configure the polling feature to look for changes and trigger a pipeline.
-
Due to restriction of company, users might not be able to expose eventlistener publicly so this could be an option which would look for changes at certain duration and trigger a Pipelinerun. Reference.
-
As a developer, I want to be able to setup an automated release process that would look at a given branch (release-vX…) and automatically schedule a build and tag a release in case there was new changes (on a weekly cadence for example). Note: it can be achieved using a
CronJobbut would be nicer to be integrated in triggers.
We have a POC done around this part of this idea described in #1168 which defines a new CRD as below.
POC tries to implement the polling feature which would look for changes and trigger a piplinerun. This integrates the Trigger template and trigger binding to use data from the response of GitHub APIs used to look for changes.
apiVersion: triggers.tekton.dev/v1alpha1
kind: SyncRepo
metadata:
name: test
spec:
repo: https://github.com/tektoncd/hub
branch: main
frequency: 3m
binding: pipeline-binding
template: pipeline-template
- This takes GitHub Repo URL and then check for changes at frequeny defined by user.
- It saves the latest commit id to status to check in further reconcilations.
-
(sbwsg) We identify CronJobs as an existing solution for scheduling. Why aren't they good enough on their own? (Ref) Cronjob do cover a use case which we are proposing which is triggering run at certain interval but to check it something is actually changed to trigger a pipelinrun/taskrun then we will need a script to check the condition. Everytime we setup this for a repository, the user will have to write a script. This logic can be abstracted into triggers and an interface can be exposed to user which would be simple to configure.
-
(sbwsg) We identify an alternative project that exists today for polling GitHub. Is there a strong reason to favor a new solution and if so what is it? Is there a strong reason to favor a project owned by Tekton and if so what is it? (Ref)
The existing solution available is an Operator. Many developer don't have access to install operators into their clusters. Providing this along with triggers which is installed by Tekton Operator will eliminate a need to install an addtional Operator. So, packaging the solution with Tekton Trigger would be nice
(To be explored)
-
Should we have both feature together?
- Trigger a pipelinerun at a certain time (cronjob/scheduling)
- Trigger a pipelinerun if something changed in repository (polling)
-
Would it make sense to
- integrated polling feature with Trigger Binding and Trigger Template? or
- keep it independent which would take pipeline as input and create a pipelinerun on a change?
- or provide both of them together?
- There is an existing implementation independent of Triggers doing similar. https://github.com/bigkevmcd/tekton-polling-operator This has an CRD which takes input and the controller check for changes and trigger a run object.