To me, any way of changing the seed job so that it does not create one global configuration of all jobs and creates it per branch basis would be a solid improvement to our CI so +1 if this is achievable without loosing currently used Jenkins' features.
Łukasz śr., 6 lis 2019 o 01:12 Alan Myrvold <[email protected]> napisał(a): > It would be a nice improvement, provided (as Luke pointed out) the same > functionality exists for triggering jobs on pull request, review comment, > postcommit, or cron and filtering jobs based on paths of files modified. > > On Tue, Nov 5, 2019 at 3:49 PM Luke Cwik <[email protected]> wrote: > >> 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 <[email protected]> >> 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: [email protected] >>> >>> Unique Tech >>> Check out our projects! <https://www.polidea.com/our-work> >>> >>
