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 

Reply via email to