| Just found this thread - and I support the purpose as well. However, maybe the thread should be renamed "Support multiple Jenkinsfiles from the same GIT repository" - as I'm doing quite a few things presently with Subversion that works very well, but just cannot be done with Git. One usecase: I've setup a large system to do automatic updates on a lot of our Debian hosts. Some runs daily, some runs weekly. They're all scheduled to run between 5 and 6 o'clock in the morning, and as the update includes a reboot, they just cannot be run in normal working hours. From 6 o'clock our normal support staff is on guard to react to failed updates - quite often by rolling back the update by reverting to a VMware snapshot that is created as part of the automatic update. If they do not need to rollback, the snapshot is deleted again by another cron-like job running at 11 o'clock. This has worked quite well for several years. Each host has it own Jenkinsfile that - among other things - run a special test after the upgrade tailored specifically for that host. The Jenkinsfiles are all stored in a single Subversion repository (Well: 25 - named A-Z - we have a LOT of hosts), and the Jenkins job is set up as a Multibranch Pipeline. Needless to say, the job has been set up to suppress automatic SCM triggering. Instead, they're triggered by the clock, and can be run manually on demand. The only gotcha so far is the fact that the job must be run manually the first time on a new host - otherwise Jenkins won't pick up the
properties([pipelineTriggers([cron('H 5 * * *')])])
statement from the Jenkinsfile. When checked out from Subversion, a repository looks like this:
Adding a new host becomes as simple as copy/pasting an existing setup and making the necessary modifications. Because of the nature of Subversion, this structure can be used in a Jenkins multibranch pipeline which will create a pipeline for each host - named after the host - and automatically create new jobs as hosts are added - and disabling existing hosts as they're deleted from Subversion. Lots of Jenkinsfiles in a single repository - a solution that works very well for us. But, unfortunately, we're slowly migrating to Git, and I haven't found a solution with Git that can do the same trick with Jenkins. Another use case: We're hosting a lot of Drupal sites and we're building and deploying these as Docker containers. I've created a Jenkinsfile and a multibranch pipeline and the code is stored in Git. My colleagues use this setup the usual way, creating feature branches in Git, merging them into a develop branch, then merging into the master branch. We deploy all the Docker containers of all the branches for testing and approval by the product owner. But the deployment jobs? These are pipelines as well - but I do not want deployment to part of the huge Jenkinsfile in the repo root. I've several reasons for that, but basically we don't want to wait hours for a long building job just to redeploy a few Docker containers. I would like very much to store the deployment jobs in the same Git repo - but with the current Jenkins pipeline functionality, I cannot - or at least I haven't figured out how to do it. So I have to maintain a separate repository for each deployment job, not an optimal situation. With Subversion I could easily do it, but as Git doesn't allow checkout of subbranches - or rather, the Jenkins SCM plugins cannot do it - I just cannot do it with Git. Just my thoughts.  |
