[BLUEPRINT] Discuss: Risor, CEL, or custom scripting and expression language?
Background
Step runner needs an expression language. @ayufan has proposed one in Draft: GitLab Steps: Add The Expression Language (gitlab!138092) • Kamil Trzciński • 17.0 which is custom-built using YACC. A working RFC implementation can be found here. @marshall007 also proposed using Risor as the expression language as it's already established. Risor would also make a good general purpose scripting language for step runner to support. And @grzesiek suggested Google's Common Expression Language (CEL).
In addition to an expression language, step runner could also use a built-in scripting language. Any scripting language can be used in steps by invoking a step which knows how to run the language. E.g. Lua could be invoked as follows:
- name: calculate_factorial_42
step: components/lua@v1
inputs:
script: |
function fact (n)
if n == 0 then
return 1
else
return n * fact(n-1)
end
end
print(fact(42))
But it would be easier to invoke if there was built-in support for the scripting language. There will be support for a step-level script
keyword that autodetects and executes a shell script: CI Steps: Iteration 2: Support `script:` syntac... (&12167) Should we do the same for a chosen scripting language? Should you be able to do this?
- name: print_current_time
script: print(time.now())
Open questions
This issue is for discussion of these open questions:
- Which language / implementation should we choose for the expression language?
- Should we add syntactic sugar for inlining scripts in a specific language?
- If yes, should it "compile" to a step invocation or be evaluated in-process?
(
Considerations
If we want a "recommended" scripting language, it would be nice to match it with the expression language. E.g. the syntax of expressions should look and feel like the syntax of scripts. So if we want to use Risor as a recommended scripting language, we should also use Risor as the expression language.
Compiling to a step should be preferred because it keeps the step runner core light weight. That's how the current script
keyword works. It is expanded into another step invocation.
Using a ready solution like Risor or CEL gives a bootstrapping boost and wider support for the language. We get improvements to the language for free (minus our upstream contributions of course). However it also brings a risk because language projects can be abandoned and we would inherit the maintenance burden. We should evaluate the likelihood of continued support, as well as the completeness of the language.