feat: add new proposal for dynamic ruleset #1026
Conversation
|
|
||
| ## Questions | ||
|
|
||
| 1. Should we name the new key `evaluation` or choose a different name? |
There was a problem hiding this comment.
I like evaluation personally.
There was a problem hiding this comment.
i know if is off the table and when is confusing in relationship to if, so evaluation seems fine if a bit lengthy. i don't feel strongly about this, but eval could be an alternative.
There was a problem hiding this comment.
I like eval instead of evaluation.
| ## Questions | ||
|
|
||
| 1. Should we name the new key `evaluation` or choose a different name? | ||
| 2. Should the new key be nested under `ruleset` or be at the same level? |
There was a problem hiding this comment.
I think I like nested. It's almost like a custom rule of sorts.
|
|
||
| 1. Should we name the new key `evaluation` or choose a different name? | ||
| 2. Should the new key be nested under `ruleset` or be at the same level? | ||
| 3. Should it be possible to use both the existing `ruleset` and the new `evaluation` feature simultaneously? If so, should both need to return true for the step to execute? |
There was a problem hiding this comment.
Yeah I think it should be possible to use both. Something like
ruleset:
event: push
branch: main
evaluation: "hasPrefix(VELA_BUILD_AUTHOR, 'Jordan')"Of course you could add the other two rules into the evaluation, but that feels a bit messy. So I like being able to declare them separately as they normally are.
Glad we are in agreement. The examples show it nested under the ruleset. I left it as an open question in case anyone thinks otherwise. |
|
|
||
| - name: new-and-old | ||
| ruleset: | ||
| evaluation: "VELA_BUILD_AUTHOR == 'JordanSussman'" |
There was a problem hiding this comment.
i think these are just pseudo examples. how would we actually access and make available the build env vars?
There was a problem hiding this comment.
how would we actually access and make available the build env vars
The example code in the expr README demonstrates how to handle the underlying code for injecting env vars. Additionally, I created a simple Go playground to showcase a more Vela-specific implementation.
There was a problem hiding this comment.
@wass3rw3rk, just to clarify, are you saying that the built-in Vela environment variables aren't available when the rulesets are evaluated, compared to how we would write the underlying expr code to inject them?
There was a problem hiding this comment.
the code example is what i was looking for - ty! i thought you had to do more to reference a variable 👍🏼
There was a problem hiding this comment.
Still need to spend some time testing it out to confirm the environments are correctly populated, but I have the initial server code changes within go-vela/server#1233.
Adding a new proposal to allow dynamic ruleset without needing to invoke templates.