I started using folders around seven months ago. The following is based on the advantages I experience in using folders, as well as the problems I've encountered. It's not a high level overview. Some of this will probably already be obsolete, but it should still serve to illustrate the kind of issues you'll be facing when trying to introduce Folders into an existing instance with expectations that existing features, plugins, and of course jobs will continue to work.
--- The good: - Coupled with commercial RBAC plugin, it's quite nice to set permissions per project folder and just delegate configuration of a project folder to the project team. Assuming you have really homogeneous roles across all projects, but that's an RBAC issue. (it's been a while since I've used Role Strategy plugin, and I haven't tried using any of the others with folders) - We have a few (Subversion SCM) projects using 'release' branches that each have a dozen or so jobs building various components. What once took almost a day of creating and configuring jobs for a new branch is now about two clicks (just copy the previous release's folder) and changing a few environment variables on the folder (Folders 3.x or Folders Plus 2.x feature). This feature alone is almost worth the problems we had. - No more juggling dozens of Nested Views just because we have a few hundred projects in our Jenkins - A nice side effect: Tools to visualize disk usage like WinDirStat or tkdu now group by project/branch/... automatically, on both master and slaves. --- That being said, the introduction of folders really wasn't a lot of fun. Some of it is my fault for assuming things would just work to a reasonable degree. I was wrong. Plugins often cannot handle folders! Some have assumptions that break down when using folders, e.g. that all items are immediate children of Jenkins, or that no two jobs have the same name. Copy Artifact, Config Slicing, Extra Columns, Role Strategy plugin, Favorite Plugin, Job Config History, all 'Wall Display' type plugins I've tried... all are or were plugins that couldn't deal properly with jobs in folders. And that's just the plugins I actually use or tried using. Try searching for unresolved issues containing 'folders support' in Jira... Then there's the issue of lacking core support for folder structures. Current 1.509.x LTS has no support for 'recursive' views, i.e. views containing not just the current item group's children, but also grandchildren etc. JENKINS-18074 and jenkins-ci.org/commit/jenkins/aa7eb7c137ad7649782683dcbbf64703982ad8f8 were annoying; JENKINS-19310, JENKINS-20003, and JENKINS-20106 still are, to varying degrees. JENKINS-20143 probably will be annoying, once I'm on 1.532.x LTS. I have _some_ hope that the situation improves now that the plugin is open source, but I expect issues like these to keep appearing for some time, especially given how stripped-down Folders 4.x is compared to Folders 3.x. --- Now, if you want to use folders, 3.x or 4.x, with or without Folders Plus plugin, here's a few tips: Don't move existing jobs into folders if they have any kind of relations to other jobs, or be prepared to fix their configs afterwards. Job Config History is helpful here. There's no internal notification for this event (JENKINS-18028), so upstream/download relations, Parameterized Trigger, Copy Artifact, Favorite plugin configurations all _will_ break. It won't break your Jenkins, but existing downstream triggers won't run, jobs with Copy Artifacts steps will fail, etc. Existing links to job URLs will break, there's no redirect. In fact, I'm currently phasing out top-level jobs heavily used as downstream (e.g. the 'Upload to public FTP site' one) by creating new jobs in folders, replacing the 'Parameterized Trigger' calls one by one, and deleting the top-level job only after they haven't been started for a few weeks. Sometimes moving jobs just isn't worth the hassle. Be aware of JENKINS-18678 if you want to take the opportunity to e.g. rename 'ProjectA-BranchB-Foo' to 'Foo' after moving it into the folder 'ProjectA/BranchB'. The builds going missing might break Copy Artifact, even if you reconfigure it. Schedule a few restarts while moving things around, just to be safe. Queued builds will be removed when you move their jobs around anyway. Folders (4.x at least) also have two minor quirks when you're on Jenkins 1.509.x LTS that might increase your support effort if you're (planning to) delegating some configuration tasks to others: - Actual 'All' views show the system message twice. Just don't use them, a folder's default view is a list view anyway - The folder's default view's inline description editor is broken Also, I have no idea how well Jenkins on Windows handles moving jobs around, but when we still had a Windows master, renaming jobs failed quite often and left behind partial job folders. I assume moving jobs would be similarly brittle. Be prepared to merge folders manually in case something goes wrong. Use the same character set for folder names as you use for job names. Folder names become part of the path to the workspace, so e.g. spaces or Unicode in folder names will break badly written tools just like spaces or Unicode in job names do. You can configure a display name so it looks nice in Jenkins. --- Then there's the issue of Folders 4 (the open source one) being a really stripped down version of Folders 3. The nicest Folders feature clearly is the ability to define environment variables on the Folder, like e.g. the SCM branch name, that can be used in all jobs in that folder. This, among a few other 'nice to have' features, now requires an Enterprise license for the Folders Plus plugin. And finally a quirk of the folders plugin to be aware of: Folders doesn't set the default view like Jenkins does. A folder's default view is not an 'All' view, but a list view with the '.*' regular expression and can be edited, so you cannot change the default view to a different view type in the folder's configuration. Regards Daniel On 28.10.2013, at 17:25, jos...@milehighcode.com wrote: > Would like to know how others have implemented the Cloudbees Folders plugin > into an existing Jenkins system. Easiest way to migrate builds into the new > namespace structure, best practices for using Folders to organize builds, etc. > > Any links to blogs or web info in addition to any mailing list responses > would be really appreciated and I am happy to link back any articles > suggested from my blog on future writings on this subject. > > -Joshua > blog.milehighcode.com > > -- > 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. > For more options, visit https://groups.google.com/groups/opt_out. -- 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. For more options, visit https://groups.google.com/groups/opt_out.
