(replies inline)
On Thu, 15 Mar 2018, Baptiste Mathus wrote:
> I thought I'd start a dedicated email here about that part after some
> feedback I got in
https://github.com/batmat/jep/pull/1.
> I know people are very busy so maybe an email is easier for many than
> looking at the PR.
Thank you for bringing this discussion back to the jenkinsci-dev@ mailing list,
I think this will give more people to an opportunity to weigh in and
consolidate our discussions into threads for easy linking in the JEP
"References" section.
More below..
> So the one the ideas I have for Essentials' data snapshotting system is to
> use the configuration parameters to put builds and workspaces under a
> single and non default root
> <
https://github.com/batmat/jep/blob/03d3404aba079b2f9b67284f6fc9940bf2ccfacd/jep/302/README.adoc#segregate-job-configuration-and-build-data>
> .
>
> Concretely, with this setting, (simplified) we'd have under *JENKINS_HOME*
> (instead of everything under *jobs* as it is usually):
> var/
> ????????? the_job
> ????????? builds
> ??? ????????? 1
> ??? ??? ????????? build.xml
> ??? ??? ????????? changelog.xml
> ??? ??? ????????? log
> ????????? workspace
> jobs/
> ????????? the_job
> ????????? config.xml
>
> Jesse <
https://github.com/batmat/jep/pull/1#discussion_r174508332> and James
> <
https://github.com/batmat/jep/pull/1#discussion_r174472740> are even
> saying we should move the var directory somewhere else *not* under
> JENKINS_HOME.
I cannot say I have ever intentionally moved /jobs/ around in this manner, I
assume that it "just works" and there's no quality concerns we should have from
a non-standard placement of data on disk?
Otherwise I have no problems with this.
> Also, saying that we should not even (try to) put the builds (and workspace
> I assume) in the Git repository, since it is not scalable.
From my understanding of the potential failure scenarios with a plugin or core
upgrade is that unreadable build.xmls won't present a problem, or be mutated by
a new plugin update, correct?
If that's the case then I don't see a problem with leaving them out of the
snapshotting system. Generally speaking, I believe we should be mostly tracking
data which will be mutated on upgrade, or other potentially high importance
data.
> I'm in mind to adjust the JEP with that proposal, though it somehow
> conflicts with that statement in the JEP-301 that "all mutable state and
> data will be written and stored in JENKINS_HOME
> <
https://github.com/jenkinsci/jep/tree/master/jep/301#mutable-data>".
When I wrote `JENKINS_HOME` I was actually just using that as a short-hand for
what is commonly understood as `/var/lib/jenkins` to most people. Basically,
mutable state should not be scattered around inside the container's temporary
filesystem, but rather contained in the single mounted volume, e.g.:
docker run -v /srv/jenkins:/var/jenkins_home jenkins/evergreen
So long as we're mounting everything through a single volume mount for the
container, my concerns/requirements for JEP-301 are met. Does that make sense
to you Ba(p)tiste?