Uploaded image for project: 'OpenShift Pipelines'
  1. OpenShift Pipelines
  2. SRVKP-8619

Enable CEL expression evaluation for template variables

XMLWordPrintable

    • 4
    • False
    • Hide

      None

      Show
      None
    • False
    • Hide
      This change adds cel: support in templates so CEL expressions can be evaluated
      inline. It exposes the body, headers, files, and pac namespaces to those
      evaluations. It enables common template logic like conditionals, presence
      checks, and simple string composition.
      Show
      This change adds cel: support in templates so CEL expressions can be evaluated inline. It exposes the body, headers, files, and pac namespaces to those evaluations. It enables common template logic like conditionals, presence checks, and simple string composition.
    • Enhancement

      Background (Required)

      The current implementation of the templating engine, found in the pkg/templates/templating.go file, limits the evaluation of Common Expression Language (CEL) expressions to variables that are prefixed with body, headers, or files. This restriction prevents users from applying CEL logic to other types of variables, such as custom ones or those derived from different contexts. As a result, expressions like {{ cel: has(body.toCommit) && body.toCommit.parents.size() > 1 ? body.toCommit.parents[body.toCommit.parents.size() - 1].id : body.toCommit.id }} fail to evaluate correctly, which restricts the functionality and expressiveness of the templates.

      Out of scope

      This story does not include a full refactor of the templating engine. The focus is specifically on updating the evaluation logic to support a new prefix for CEL expressions. It also does not include the creation of new built-in functions or variables for the CEL environment.

      Approach (Required)

      Add a new prefix for CEL evaluation: Modify the pkg/templates/templating.go file to recognize a new, dedicated prefix (e.g., celExpr) for evaluating CEL expressions.

      Update the evaluation logic: Extend the if strings.HasPrefix(...) condition to include the new prefix. For example, if strings.HasPrefix(key, "body") || strings.HasPrefix(key, "headers") || strings.HasPrefix(key, "files") || strings.HasPrefix(key, "celExpr").

      Process the expression: When a variable with the cel prefix is encountered, the code should strip the prefix and evaluate the remaining string as a CEL expression.

      Test the functionality: Ensure that the provided example {{ cel: has(body.toCommit) && body.toCommit.parents.size() > 1 ? body.toCommit.parents[body.toCommit.parents.size() - 1].id : body.toCommit.id }} evaluates correctly and that the output is properly rendered in the template.

      Dependencies

      No external dependencies identified. This is a self-contained code change.

      Acceptance Criteria (Mandatory)

      A template variable prefixed with cel: must be evaluated as a CEL expression.

      The expression {{ celExpr: has(body.toCommit) && body.toCommit.parents.size() > 1 ? body.toCommit.parents[body.toCommit.parents.size() - 1].id : body.toCommit.id }} should correctly return the last parent commit ID for a merge commit and the commit ID itself for a standard commit.

      Variables without the cel: prefix should continue to function as they do currently, without being evaluated as an expression.

      Documentation for the new cel prefix must be updated to reflect this new functionality.

      INVEST Checklist

          ( ) Dependencies identified
          ( ) Blockers noted and expected delivery timelines set
          ( ) Design is implementable
          ( ) Acceptance criteria agreed upon
          ( ) Story estimated

      Legend

          ( ) Unknown
          ( ) Verified
          ( ) Unsatisfied

      Done Checklist

       * Code is completed, reviewed, documented and checked in
       * Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
       * Continuous Delivery pipeline(s) is able to proceed with new code included
       * Customer facing documentation, API docs etc. are produced/updated, reviewed and published
       * Acceptance criteria are met

              cboudjna@redhat.com Chmouel Boudjnah
              cboudjna@redhat.com Chmouel Boudjnah
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: