Add CEL macro to fetch data from ConfigMap

[pbaity]

Feature request

The cel interceptor already offers extension functions to compare data from an event's body or headers to a Kubernetes Secret with compareSecret(), which can look like this:

interceptors:
  - ref:
      name: cel
    params:
      - name: filter
        value: "header.canonical('X-Secret-Token').compareSecret('key', 'secret-name')"

or, including the namespace of the Secret:

- name: filter
  value: "header.canonical('X-Secret-Token').compareSecret('key', 'secret-name', 'namespace')"

"Reading" from Secrets (for comparison) is a great feature, but there's no way for CEL to read a value from a ConfigMap. My initial thought was to add an extension function for compareConfigMap() or something like that, but I think it'd be better to just allow fetching from ConfigMaps with a function/macro. Maybe it could look like this:

- name: filter
  value: "readConfigMap('data', 'my-configmap', 'my-namespace') == 'data-from-configmap'"

or, more realistically:

- name: filter
  value: "body.repository in readConfigMap('data', 'watched-repositories')"

There is probably a better name for that macro, but that's the gist.

Use case

I can think of several, but probably there are way more:

1. EventListeners and Triggers could change their behavior (i.e., whether they "activate") based on feature flags in a ConfigMap. For example, a Trigger could see if a setting is true or false in a ConfigMap in a filter to decide whether to activate.
2. A single EventListener could serve multiple repositories that use different Triggers based on a ConfigMap mapping repositories to Triggers. For example, a team with many microservice repositories could easily update the ConfigMap to control which Triggers should activate for each microservice repository. This would help with cases like those in Dynamic triggering of triggerGroups #1474
3. Users don't have any way to read from ConfigMaps without writing custom interceptors in Go; being able to define simple behaviors with CEL based on reading from ConfigMaps could allow users to get a lot more power out of EventListeners and Triggers without writing custom interceptors

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

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

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/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 with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/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.

[khrm]

/remove-lifecycle rotten

[khrm]

/reopen

[tekton-robot]

@khrm: Reopened this issue.

In response to this:

/reopen

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.

[rkr-kununu]

I'd also really be interested in such a feature. I've got a use-case similar to:

tektoncd/pipeline#4080 (comment)

Basically, I have a single building pipeline for multiple different projects. I'd like the resource limits to be unique (optimized) for each project, which is only possible in a PipelineRun.

As tekton-triggers, currently, have no way of fetching content outside of the webhook request to enrich the content of the Trigger. This greatly limits the usefulness of Triggers. As, I'm using github webhooks - my only option is adding a bunch of github labels (which is noisy).

If it were possible to fetch content from a ConfigMap, I could simply choose the correct configmap (based on the git-repo name or some other meta data).