Poll based change detection?

[bobcatfish]

(moved from tektoncd/pipeline#1489 by @evgf)

Expected Behavior

It should be possible to trigger on any change to the state of a repo (i.e. poll based).

(I'm assuming we're talking about the content of the repo itself, but maybe we're also talking about stuff like PRs, issues and comments?)

Actual Behavior

Currently we provide support or at least docs for:

• Triggering based on the passage of time (cron)
• Triggering when a webhook endpoint is hit

Additional Info

Not sure how in scope this really is for triggers - it could be something that makes more sense in the catalog? Either way I think a lot of folks are going to want something like this.

[dibyom]

/kind feature

[vdemeester]

Not sure how in scope this really is for triggers - it could be something that makes more sense in the catalog? Either way I think a lot of folks are going to want something like this.

I am also not sure if it is in the scope of triggers (or documentation would be, but as a feature ?).

If it is a feature in triggers, as it is poll-based, we wouldn't need an event-listener (because event-listener is for "push-based"), so on which resource should it be ?

[bigkevmcd]

I'm interested in this sort of functionality, but what would it mean within a "triggers" context?

Detect changes, and trigger a PipelineRun or TaskRun with the changes, maybe the RepoURL and SHA?

[sbose78]

Poll based change detection would be nice to have!

[vtereso]

With consideration for #478, I really like the idea of focusing Triggers around the EventListener paradigm (listening to events). Polling is a bit different, but for locations that don't have webhooks builtin, I like it. This also has the benefit of making it so the service doesn't have to be exposed?

[TomaszKlosinski]

That's a blocker for my company. We're not allowed to expose EvenListener to the public Internet. This feature would solve this issue. I suppose this might be a common case for bare metal Kubernetes installations behind NAT/firewall with git repos on GitHub.

[bigkevmcd]

@TomaszKlosinski https://github.com/bigkevmcd/tekton-polling-operator might work for you, it's a very early version, but it will poll repositories and trigger pipelines.

If it doesn't, I'd be really interested to hear what's missing :-)

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[dibyom]

/lifecycle frozen

[verokarhu]

@TomaszKlosinski https://github.com/bigkevmcd/tekton-polling-operator might work for you, it's a very early version, but it will poll repositories and trigger pipelines.

If it doesn't, I'd be really interested to hear what's missing :-)

I notice that it's an operator which to me seems like overkill. First, many developers don't have access to install operators into their clusters. Second, making a poll-based trigger should be trivial with existing functionality. Unless I'm missing something, this should already do the bare minimum of polling for changes in the repository:

1. CronJob runs periodically, triggering a TaskRun.
2. TaskRun checks for the latest SHA in the repository and compares it to the previous one which was stored on a permanent PVC which contains state.
3. If there was a change, TaskRun triggers a build.

[dmikalova]

Using cron for poll based triggering as a paradigm also makes sense because it can support polling things other than commits to a git repo - for example releases in github or gitlab, changes to an s3 bucket, release published on an arbitrary downloads page, etc. Each of these options can be available in the catalog.

[cdaf]

Has there been any movement on this issue. Was considering moving from Jenkins server to Tekton within our cluster, seemed like a nice integrated solution, but wow, it's a lot more complicated than I ever imagined.

So after much learning I have my pipeline defined, but as I'm working in a CRC instance, I cannot expose it public, so I need an outreach solution. I'm currently considering running a GitHub Runner in a container, and use GitHub action to invoke the pipelineRun from the Runner, pretty wonky I admit, so keen to find a native solution for this.

[vdemeester]

/area roadmap