Hi all, As those of you that work on Jenkins jobs know, they can be a pain to work with. Even simple changes are painful to run in the PR because of the seed job - it reloads all the jobs sequentially and runs for over 10 minutes. If someone else runs it against another branch - tough luck, you need to retrigger it, because your configuration changes are lost.
The reason it looks like that is Jenkins and its architecture. All job configurations are stored on the Jenkins master node in the form of XML job definitions. Job DSL is just a plugin which enables translation of Groovy scripts to XMLs. I looked into improving the situation and it seems that a good solution would be to move from Job DSL-defined Jenkins jobs to Jenkinsfiles. The move would make starting the seed job for every change in job configuration unnecessary, making the process much faster and more flexible for people working on the tests simultaneously. Jenkinsfile-based jobs are, in essence, very similar to conventional Jenkins jobs - the configuration is still stored as XML in the Jenkins master, but the main thing stored there is the path to a Jenkinsfile. This way, by using a plugin, it’s possible to interpret a Jenkinsfile on the fly without having the exact job step sequence stored on Jenkins master. Thus it’s possible to run a pipeline job with branch name as parameter and load a different Jenkinsfile for each branch the job is ran against. Since it is possible to define a Jenkinsfile-based pipeline job in Job DSL, we could keep the seed job and use it only to create and/or deactivate jobs as needed not to reload every, even tiny change in .jenkins directory. Actual task configurations and job steps would be defined in Jenkinsfiles, which would be read on a per-branch basis. I’m well aware that migrating all the Jenkins jobs (88 files worth of jobs) would be a huge task, but I believe that it would make future modifications of jobs much easier, as well as reduce the bottleneck of job modification testing - the seed job. It’s also probable that Jenkinsfile based job configs would be testable, which could further improve the job creation and modification process. What do you think about this? Have a good day, Michal -- Michał Walenia Polidea <https://www.polidea.com/> | Software Engineer M: +48 791 432 002 <+48791432002> E: michal.wale...@polidea.com Unique Tech Check out our projects! <https://www.polidea.com/our-work>
