I have to agree with Jeremy on this. Using a templating engine like m4 or jinja2 is superior to programmatic generation of groovy, if you need to do it on the fly. Why? Simplicity and Readability.
I inherited a build system that is based on using a multibranch pipeline with a Jenkinsfile that loads and executes a groovy script that's generated on the fly based on input from structured data from json files found alongside the Jenkinsfile in the repo. So, yeah, it's basically a hand-rolled solution to parametrizing a job. It sounds like that's basically what you're trying to accomplish as well, Jeff. The part I don't like is the way we're generating the groovy code. We've a library of python code that uses classes and a streaming approach to outputting all the syntax required to implement the pipeline. First of all, there's a high learning curve to using this approach - when trying to determine what the groovy output will look like you have to run the code and look at the output, which is a whole software development process in and of itself. When making changes, instead of using a template with variable substitution and loops perhaps, with the programatic approach, you have to write (and test and debug) code to make the groovy code you want. A template already resembles what the final output (groovy) will look like, so it's quite intuitive to work on. Also, every time you need to use a new groovy construct, with the programatic approach, you have to add support for it in your code gen library. With the template you just write it, based on the pipeline syntax documents. This brings up another reason why templated approach is superior: Programatic approach obfuscates the details of the language from the code gen developer. Looking back and forth between the jenkins pipeline syntax docs and a template is straightforward, not so with a library of classes defined to generate groovy. So, that's my $0.02. I plan to refactor our code gen library to use jinja2 templating to make our pipelines more intuitive and easier to work with. Another thing related to keep in mind is that, as far as I can tell, the "load" command, which is the mechanism you would use to actually run your generated pipeline script, is designed to work with Scripted Pipeline, not Declarative. This distinction is very poorly documented by Cloudbees, IMO. Please chime in if you have more info on dynamic generation and running of pipeline code. On Tuesday, October 1, 2019 at 8:43:25 AM UTC-7, Jeff Sault wrote: > > Does anyone know of any libraries/tools that will allow me to > add/remove/update sections of a Jenkinsfile programatically? I have a load > of different projects which I need to update to include some new mandatory > parameters. I'd like to go down the 'shared library' route but in this > instance its not really possible. Parsing the jenkinsfile is non-trivial > but I assume theres something in groovy/jenkins land which can already do > the job. > > Thanks > Jeff > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/d77f7156-b8b9-4b65-9959-1aad8a39f2a5%40googlegroups.com.
