Proposal: Introduce new CRD for CEL

[vincent-pli]

Feature request

We already has experimental project cel
That's very useful, but one shortage: cannot evaluate expression with a predefined variable.
for example: job_priority in ['high', 'normal'] ? 'Sev-1' : 'Sev-2'
The job_priority is a predefined variables somewhere.

To handle the gap, one solution is introduce the dependency between the params:

apiVersion: tekton.dev/v1alpha1
kind: Run
metadata:
  generateName: celrun-with-context-
spec:
  ref:
    apiVersion: cel.tekton.dev/v1alpha1
    kind: CEL
  params:
    - name: name
      value: "'hello'"
    - name: types
      value: "type(name)"
    - name: expression-use-context
      value: "name + ' is type of ' + types"

basically, the idea is the subsequent param could leverage previously param for evaluation, see the type(name) leverage the name which is the first param. it has been implements in the PR: tektoncd/experimental#717

That's could work, but not good enough, a better solution is to define a dedicated CRD for it, fortunately there is no CRD in cel for now.

A draft idea is:

apiVersion: custom.tekton.dev/v1alpha1
kind: CEL
metadata:
  name: example
spec:
  vars:
  - name: job_priority
    value: high
  - name: alert_enable
    value: "true"

We have vars to store variables which will be leveraged by evaluation.

There should be two scenario:

• Run.spec.ref with name

apiVersion: tekton.dev/v1alpha1
kind: Run
metadata:
  generateName: celrun-with-context-
spec:
  ref:
    apiVersion: custom.tekton.dev/v1alpha1
    kind: CEL
    name: example
  params:
    - name: job_severity
      value: "job_priority in ['high', 'normal'] ? 'Sev-1' : 'Sev-2'"
    - name: types
      value: "type(job_severity)"
    - name: alert_enable
      value: "false" 

Then the variables defined in CR: example will be leveraged by evaluation, and after calculated the new expression and its result will be add to example.

• Run.spec.ref with no name

apiVersion: tekton.dev/v1alpha1
kind: Run
metadata:
  generateName: celrun-without-context-
spec:
  ref:
    apiVersion: custom.tekton.dev/v1alpha1
    kind: CEL
  params:
    - name: red
      value: "{'blue': '0x000080', 'red': '0xFF0000'}['red']"
    - name: blue
      value: "{'blue': '0x000080', 'red': '0xFF0000'}['blue']"
    - name: is-red
      value: "{'blue': '0x000080', 'red': '0xFF0000'}['red'] == '0xFF0000'"
    - name: is-blue
      value: "{'blue': '0x000080', 'red': '0xFF0000'}['blue'] == '0xFF0000'"

The behavior will keep same with current implements.

Need your feedback:
/cc @jerop @afrittoli

Use case

[vincent-pli]

@jerop @afrittoli
What do you think?

[jerop]

@vincent-pli thank you for the detailed description 😁

makes sense that we provide a way to pass in variables to the CEL environment

for example: job_priority in ['high', 'normal'] ? 'Sev-1' : 'Sev-2'
The job_priority is a predefined variables somewhere

how are you using the job_priority variable? please expound on this example so that we understand the practical scenario or use case better

That's could work, but not good enough, a better solution is to define a dedicated CRD for it, fortunately there is no CRD in cel for now

this may be the solution, but let's explore other alternatives before we go forward with adding a CEL CRD

for example, we could avoid adding a CRD by adding variable and expression prefix before a Parameter to indicate whether it's a variable for the CEL environment or a CEL expression to be evaluated, as such:

apiVersion: tekton.dev/v1alpha1
kind: Run
metadata:
  generateName: celrun-with-context-
spec:
  ref:
    apiVersion: custom.tekton.dev/v1alpha1
    kind: CEL
  params:
    - name: variable.job_priority
      value: "high"
    - name: expression.job_severity
      value: "job_priority in ['high', 'normal'] ? 'Sev-1' : 'Sev-2'"

[jerop]

if we decide to add a CRD, another alternative is to specify the expressions in the CRD and the variables as Parameters, as such:

apiVersion: custom.tekton.dev/v1alpha1
kind: CEL
metadata:
  name: example
spec:
  expressions:
    - name: job_severity
      value: "job_priority in ['high', 'normal'] ? 'Sev-1' : 'Sev-2'"

apiVersion: tekton.dev/v1alpha1
kind: Run
metadata:
  generateName: celrun-with-context-high-
spec:
  ref:
    apiVersion: custom.tekton.dev/v1alpha1
    kind: CEL
    name: example
  params:
    - name: job_priority
      value: high
---
apiVersion: tekton.dev/v1alpha1
kind: Run
metadata:
  generateName: celrun-with-context-low-
spec:
  ref:
    apiVersion: custom.tekton.dev/v1alpha1
    kind: CEL
    name: example
  params:
    - name: job_priority
      value: low

this is better for reusability because the CEL expressions can be evaluated in multiple Runs with different environment variables (as Parameters)

[vincent-pli]

Thanks @jerop
Based on previously discussion, we want to resolve two issue:

• Evaluate expression with a predefined variable
• Reusability

so we can combine them:

apiVersion: custom.tekton.dev/v1alpha1
kind: CEL
metadata:
  name: example
spec:
  vars:
   - name: job_priority
     value: high
   - name: alert_enable
     value: "true"
  expressions:
    - name: job_severity
      value: "job_priority in ['high', 'normal'] ? 'Sev-1' : 'Sev-2'"

The vars aim to supply variables as context, the variables in vars could be:

1. Predefined by user
2. From the evaluated result of run.params

The expression is for reusability, the items in expressions will be evaluated every time the CR referred.
All items in expressions and vars will be add to the results of run.

For example:

apiVersion: tekton.dev/v1alpha1
kind: Run
metadata:
  generateName: celrun-with-context-low-
spec:
  ref:
    apiVersion: custom.tekton.dev/v1alpha1
    kind: CEL
    name: example
  params:
    - name: job_severity_old
      value: "job_priority in ['high', 'normal'] ? 'Sev-1' : 'Sev-2'"
    - name: job_priority
       value: low

The job_severity_old will calculated based on variables pre-defined in CR, the get job_severity_old=Sev-1
then job_priority will be update to low,
finally, we calculate items in expressions, get job_severity=Sev-2

Then, the CR will looks like this:

apiVersion: custom.tekton.dev/v1alpha1
kind: CEL
metadata:
  name: example
spec:
  vars:
   - name: job_priority
     value: low
   - name: alert_enable
     value: "true"
   - name: job_severity_old
     value: "Sev-1"
  expressions:
    - name: job_severity
      value: "job_priority in ['high', 'normal'] ? 'Sev-1' : 'Sev-2'"

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