This would be great. I believe someone tried this in the past but it turned out somehow the plugin they were using didn't support the same github hooks so we couldn't have PRs start Jenkins jobs automatically and there may also have not supported a path regex that allowed us to filter out Jenkins jobs from running on all PRs.
On Tue, Nov 5, 2019 at 6:13 AM Michał Walenia <michal.wale...@polidea.com> wrote: > 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> >
