Daniel, Thank you so much for the thorough discussion of the experience you've had with the plugin. I will definitely begin with a small environment to test this out, over migrating the whole enchilada of builds. I really appreciate you sharing your perspective!
-Joshua On Monday, October 28, 2013 3:55:44 PM UTC-6, Daniel Beck wrote: > > 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/aa7eb7c137ad7649782683dcbbf64703982ad8f8were > 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, [email protected] <javascript:> 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 [email protected] <javascript:>. > > 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
