pipeline
pipeline copied to clipboard
tektoncd
allow more complex when conditions, minimally regex
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.
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 thanks for the work around idea. I will give it a try and report back. and I like the new operator idea.
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.
Also the default behavior of:
If all the WhenExpressions evaluate to True
Needs any option to toggle the behavior to be:
If ANY of the WhenExpressions evaluate to True
I have this scenario where I have multiple spawned tasks, and if any ONE of them fails, I need something else to run.
@itewk @bitsofinfo check out the newly-added common expression language custom task which may be helpful for your use cases
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.
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.
Is this being actively worked on somewhere? Or is this something I could help out with? We would love to have this natively in Tekton for our users to write their own when expressions with basic regex matching rather than deal with a custom task.
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.
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.
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.
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: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopenwith a justification. Mark the issue as fresh with/remove-lifecycle rottenwith a justification. If this issue should be exempted, mark the issue as frozen with/lifecycle frozenwith 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.
/reopen
Its hard to believe this is not a feature, WhenExpressions are so limited limited without it, honestly its hard be believe this wasn't part of the initial deployment.
@jacobbrozenick: You can't reopen an issue/PR unless you authored it or you are a collaborator.
In response to this:
/reopen
Its hard to believe this is not a feature,
WhenExpressionsare so limited limited without it, honestly its hard be believe this wasn't part of the initial deployment.
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.
@bitsofinfo: You can't reopen an issue/PR unless you authored it or you are a collaborator.
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.
@bitsofinfo: You can't reopen an issue/PR unless you authored it or you are a collaborator.
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.
@jerop: Reopened this issue.
In response to this:
reopening on behalf of @bitsofinfo
/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.
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.
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.
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.
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.