-
Notifications
You must be signed in to change notification settings - Fork 420
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Rego interceptor #484
Comments
/kind feature |
Rotten issues close after 30d of inactivity. /close Send feedback to tektoncd/plumbing. |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
@tekton-robot: Closing this issue. In response to this:
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. |
/remove-lifecycle rotten |
I think this would be a really cool feature to have, since it would enable managing an reusing policies - which with CEL can only be copy/pasted across event listeners. Once example would be filtering GitHub webhook events based on the |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
/remove-lifecycle rotten |
with the work done for the v0.13 release, I think this is a great time to invest in further interceptor patterns. I'm going to take a look at the previous implementation by @bobcatfish and see how it can be adapted into the current deployment structure for the triggers-core-interceptors. With the plugin model, we could make this an optional alpha feature for some time and even allow it to be deployed separately within a triggers deployment. |
I took a slightly different approach now that we can allow for arbitrary JSON parameters in an interceptor expression. The base module is set at You can then write additional queries based off that initial compiled module (which we then only have to compile once). Those queries will be evaluated and binding variables will locate each match to become a set of extension keys. I put some notes in the docs, but maybe it will be best to bring the solution to WG soon. |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
Rotten issues close after 30d of inactivity. /close Send feedback to tektoncd/plumbing. |
@tekton-robot: Closing this issue. In response to this:
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. |
Expected Behavior
In addition to supporting CEL for filtering and mutation of payloads, we can support other options out of the box, such as Rego.
Actual Behavior
We only support CEL, tho folks can bring their own interceptors of course!
Additional Info
To actually make this happen we should propose a design since there are a few ways we could express filtering + overlays with Rego.
This is a POC of a Rego interceptor. It uses a
filter
query and anoverlay
query which provides the same functionality as this example CEL interceptor.Preview of the rego syntax:
This yaml is an example that uses the pullrequest task to comment on a PR when it is opened.
The text was updated successfully, but these errors were encountered: