I think it's a genuinely great proposal and it sounds like most of the things I'd be concerned about have already been thoroughly considered and addressed effectively. There are two remaining points to consider:
I think it might be desirable to give plugins some mechanism to interact with the Gitignore (or an equivalent) -- at least for cases where there's a non-standard storage mechanism that needs to be included in the SNAPSHOT (or excluded). Extra flexibility will also help with addressing any edge-case issues that might crop up, and enables the project to push some of the pain onto plugin maintainers if they're (ab)using the Filesystem in non-idomatic (for Jenkins) ways that are hard to support. I say that in the nicest way, hoping that I'm not a guilty party. Also, I do worry a bit that we might encounter compatibility issues when separating the job config from their builds -- probably plugins doing something relative to the ITEM directory (which is *wrong*, but could still happen). I know some of our senior Jenkins engineers don't see any issues with breaking plugins that are Doing It Wrong (tm), but generally I'd like to see some testing across different plugins and a healthy beta period with *healthy in-the-wild-use *just to ensure positive user experiences. Relocating build records isn't done as often aside from expert installations, and less experienced users won't be able to distinguish between "Evergreen broke me" and "some random plugin broke because that wasn't respecting the build record directory." Also this burn-in-testing period will help us identify and build out the rules for what to include/exclude in snapshots. Bonuses: I like *a lot* that we're limiting the scope to just upgrade/downgrade and not trying to use this as a general-purpose backup. It might even be desirable to limit the Git history in some fashion to prevent it becoming bloated. In general this is a well-considered and valuable addition to the Jenkins ecosystem. Should generally help with performance -- especially if we end up splitting into a couple volumes down the road which can be relocated to faster/slower performance as needed. On Monday, March 26, 2018 at 8:49:17 AM UTC-4, Stephen Connolly wrote: > > I see nothing wrong with it... but I would say that having added the > --pluginroot option myself iirc ;-) > > On 24 March 2018 at 00:29, Sam Gleske <[email protected] <javascript:>> > wrote: > >> I normally store expanded plugin metadata within >> /var/cache/jenkins/plugins similar to how WAR filre metadata is stored in >> /var/cache/jenkins/war. >> >> Is there any particular reason the Jenkins packages don't do this? Are >> there any drawbacks? I'm curious if others have any opinions on this. >> >> I've been running Jenkins quite a while like this. >> >> [1]: >> https://github.com/samrocketman/jenkins-bootstrap-shared/blob/1a409cad89007f56ed36342427b767dd4e88fbd9/packaging/docker/run.sh.in#L38 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/05beb1e5-a824-428c-b980-07a4e343acdc%40googlegroups.com >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1434c647-7743-4cb7-9d18-d1d58beb7e95%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
