Pipeline: allow more complex when conditions, minimally regex

Created on 28 Oct 2020 · 5Comments · Source: tektoncd/pipeline

Feature request

currently the when statement that replaced the Condition CRD only has the ability to check if a given string is in a list of other strings. This is limiting.

Need the ability to at the least do pattern matching, ex, regex.

Use case

Transitioning from a Jenkins pipeline to a Tekton pipeline. In Jenkins have when condition on steps to check the branch and compare it against patterns to decide whether to exuecute the step. IE, for "PROD deploy" step verify that on the main or release/.* branch and for "Merge Request Deploy" check feature/.*. When translating to Tekton there is no way to do this blocking our ability to translate the logic.

Other

This is the problem bit, that it has a hard coded == https://github.com/tektoncd/pipeline/blob/master/pkg/apis/pipeline/v1beta1/when_types.go#L82. Need the ability to control that operation, or just change that op to a regex match which then will work for == as well.

Ideally this wouldn't be hard coded and rather any arbitrary function that returns true/false could be supplied to make the deicion to future proof against any possible future ways someone may want to add a condition to a step.

kinfeature

Source

itewk

👍10 🎉1

Most helpful comment

For now, you could possibly solve your use case by creating a Task that compares a _branch_ Param against a _pattern_ Param and produces a Result indicating whether it _matches_....then use that Result in WhenExpressions to guard the subsequent Tasks

Separately, one alternative for supporting regex matching in WhenExpressions is by adding another Operator (maybe Matches) instead of modifying the In and NotIn Operators

jerop on 29 Oct 2020

👍3

All 5 comments

Separately, one alternative for supporting regex matching in WhenExpressions is by adding another Operator (maybe Matches) instead of modifying the In and NotIn Operators

jerop on 29 Oct 2020

👍3

@jerop thanks for the work around idea. I will give it a try and report back. and I like the new operator idea.

itewk on 29 Oct 2020

👍1

Definitely need more flexibility w/ WhenExpressions:

All standard operators should be supported (in, not in, >, <, >=, <= and ==/!= aliased to in/notin just to be friendly

Ideally just supporting an "expression" literally via CEL (+regex like the op requested) would be great to. Really can just open it up to more possibilities you can't predict. Keep it as open as possible. https://github.com/tektoncd/pipeline/issues/2812

Here is my scenario:

I have a task who's result is a metric. Then whether or not a subsequent task proceeds is based if that metric meets a threshold. (think, <=, >=, <, > etc)

I guess I could change the task's "result" to be an "interpretation" of that metric that is compatible with what WhenExpression currently supports (or create an intermediary Task that interprets the result, then the interpreters result becomes the input to the WhenExpression) but this all seems like hoops to jump through.

I think of tasks like functions. the caller (pipeline) makes the interpretation of the result from the call to the function, not the function itself. The caller in this case is the pipeline and the function is the task who's "output/result" is a metric. I want to be able to re-use my task that "does X and returns metric" and not tightly couple it to the context its used in by doing the interpretation of the result itself. In diff contexts (pipelines) where/when the task is invoked, the metric result can be interpreted in diff ways.

Do be able to do this requires a more flexible "interpreter" mechanism if WhenExpression is the only means currently to do it now (outside of deprecated conditions) or intermediary "result generator/interpretor tasks". Its just too limited with in/notin imho

leverage the power of all the various expression dsls out there to open it up to a "context object" that contains all the pipeline params, task results and just let the operator (user) craft an expression of what they need to evaluate.