3 ms·
What if it's config for CI (i.e. Jenkins)? In that case your "config" needs to support branching ("build this if master else build that").
by umvi 7y ago
What if it's config for CI (i.e. Jenkins)? In that case your "config" needs to support branching ("build this if master else build that").
- kakwa_ 7y agoCI systems tends to be more about defining a workflow than setting simple parameters, specially if they also handle CD. For that reason, something looking more like a programing language feels more appropriate to me. I kind of like the Jenkinsfile syntax for this use case as a CI workflow is not a static definition defined by a configuration file (yaml, json or ini) but the syntax is also not a fully "open" programing language like Python which would authorize too many potential hacks. A specialized DSL in this case seems more appropriate and being the correct balance between flexibility and complexity, at least for most needs.
- yongjik 7y agoI don't know Jenkins, but my take is that "DSL is good, dynamic full-language config is bad." If you need a fully programmable environment, then you need a fully programmable environment. The important thing is that the DSL is a well-defined contract between what you specify and what the underlying software does, so if you say "If X then do Y", then that's exactly what it does. You should be able to follow the DSL line-by-line and debug it. (You've probably noticed that I'm not a fan of declarative languages a la Makefile: you can never figure out where things "start" and "end".) A "full language config" (like Python) is much worse than DSL: usually there's no clear semantics about when any snippet is executed, yet it's powerful enough to bring in the whole outside environment, which is what's going to happen in a team with 5+ people.