Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-21942

Unreliable defaulting of Jenkins.workspaceDir

      Jenkins.workspaceDir is supposed to default to $JENKINS_HOME/workspace/ on new installations: the "modern" location, consistent with that of slaves. But if you do not save the Jenkins global configuration during the first startup, on the next startup $JENKINS_HOME/jobs/ exists yet $JENKINS_HOME/config.xml does not, so the "compatibility" code kicks in and the old location is used!

      Just setting this field to the new value in the instance initializer probably does not suffice, since installations upgraded from before the introduction of this field would be incorrectly switched to the new value.

      Probably suffices to adjust the check to also check for the existence of $JENKINS_HOME/config.xml, since most old installations would have saved this file at least once.

          [JENKINS-21942] Unreliable defaulting of Jenkins.workspaceDir

          Jesse Glick added a comment -

          batmat in some ways this is actually worse after JENKINS-50164, because if for example you had a working instance and then deleted $JENKINS_HOME/config.xml (say, to fix a security lockout), Jenkins will quietly reset those values to

            <workspaceDir>${ITEM_ROOTDIR}/workspace</workspaceDir>
            <buildsDir>${ITEM_ROOTDIR}/builds</buildsDir>
          

          and there is no way to fix the OLD_DEFAULT_WORKSPACES_DIR from the GUI.

          Probably we should just throw out the old default and unconditionally default to DEFAULT_WORKSPACES_DIR. There is little real compatibility risk here even for installations that had been using the old location—they will have some stranded workspaces, and the first new build of each job will need a full SCM clone rather than update, but that seems a tolerable price to pay to fix this once and for all.

          Jesse Glick added a comment - batmat in some ways this is actually worse after JENKINS-50164 , because if for example you had a working instance and then deleted $JENKINS_HOME/config.xml (say, to fix a security lockout), Jenkins will quietly reset those values to <workspaceDir> ${ITEM_ROOTDIR}/workspace </workspaceDir> <buildsDir> ${ITEM_ROOTDIR}/builds </buildsDir> and there is no way to fix the OLD_DEFAULT_WORKSPACES_DIR from the GUI. Probably we should just throw out the old default and unconditionally default to DEFAULT_WORKSPACES_DIR . There is little real compatibility risk here even for installations that had been using the old location—they will have some stranded workspaces, and the first new build of each job will need a full SCM clone rather than update, but that seems a tolerable price to pay to fix this once and for all.

          David Aldrich added a comment -

          batmat I see this message in our console log:

          Feb 18, 2019 8:29:06 AM WARNING jenkins.branch.WorkspaceLocatorImpl getWorkspaceRoot
          JENKINS-2111 path sanitization ineffective when using legacy Workspace Root Directory ‘${ITEM_ROOTDIR}/workspace’; switch to ‘${JENKINS_HOME}/workspace/${ITEM_FULL_NAME}’ as in JENKINS-8446 / JENKINS-21942
          

          I don't understand the message. Please will you suggest how I can fix the problem in our Jenkins installation?

          David Aldrich added a comment - batmat I see this message in our console log: Feb 18, 2019 8:29:06 AM WARNING jenkins.branch.WorkspaceLocatorImpl getWorkspaceRoot JENKINS-2111 path sanitization ineffective when using legacy Workspace Root Directory ‘${ITEM_ROOTDIR}/workspace’; switch to ‘${JENKINS_HOME}/workspace/${ITEM_FULL_NAME}’ as in JENKINS-8446 / JENKINS-21942 I don't understand the message. Please will you suggest how I can fix the problem in our Jenkins installation?

          David Moles added a comment -

          I'm seeing the same, in a Docker image configured with JCasC.

           

          David Moles added a comment - I'm seeing the same, in a Docker image configured with JCasC.  

          Shannon Kerr added a comment - - edited

          batmat I'm seeing the same.  Do we know what needs to be done to correct this?  Per jglick on JENKINS-2111 this is not something we should ignore.

          Shannon Kerr added a comment - - edited batmat I'm seeing the same.  Do we know what needs to be done to correct this?  Per jglick on JENKINS-2111 this is not something we should ignore.

          Baptiste Mathus added a comment - - edited

          I think we are going to try and look into this, but anyone feel free to give it a shot if you feel like it. See https://github.com/jenkinsci/jenkins/pull/3364 partly for hints, as it touches mainly the related code area.

          Fixing this should not be too hard for an experienced Java developer.

          *UPDATE: also, dmolesuc3 it would be very interesting if you can provide a GitHub repo for such a Docker image demonstrating the issue. Definitely should help fixing this more quickly.
          UPDATE2: as said by Jesse too, if you are seeing this, this would also mean you are building on the master node, which is generally strongly discouraged.*

          Baptiste Mathus added a comment - - edited I think we are going to try and look into this, but anyone feel free to give it a shot if you feel like it. See https://github.com/jenkinsci/jenkins/pull/3364 partly for hints, as it touches mainly the related code area. Fixing this should not be too hard for an experienced Java developer. *UPDATE: also, dmolesuc3 it would be very interesting if you can provide a GitHub repo for such a Docker image demonstrating the issue. Definitely should help fixing this more quickly. UPDATE2: as said by Jesse too, if you are seeing this, this would also mean you are building on the master node, which is generally strongly discouraged.*

          Jesse Glick added a comment -

          My suggestion as of 2018-04-24 is to just toss out the partially broken compatibility code and only mention the recommended location in the code. Simpler and probably good enough.

          Jesse Glick added a comment - My suggestion as of 2018-04-24 is to just toss out the partially broken compatibility code and only mention the recommended location in the code. Simpler and probably good enough.

          Kanstantsin Shautsou added a comment - - edited

          Now it's impossible to run Jenkins on relative dir path. If i pass into jenkins rule target/somedir it fails because Jenkins instance itself can work without issues, but this check throws and fails.
          Fresh Jenkins object has no config.xml in JenkinsRule, then checks {{ checkRawBuildsDir(buildsDir);}} where buildDir is "${ITEM_ROOTDIR}/builds" by default
          (stacktrace from 2.176.4)

          08:51:16 org.jvnet.hudson.reactor.ReactorException: java.io.IOException: jenkins.model.InvalidBuildsDir: ${ITEM_ROOTDIR}/builds does not resolve to an absolute path
          08:51:16 	at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:282)
          08:51:16 	at jenkins.InitReactorRunner.run(InitReactorRunner.java:48)
          08:51:16 	at jenkins.model.Jenkins.executeReactor(Jenkins.java:1129)
          08:51:16 	at jenkins.model.Jenkins.<init>(Jenkins.java:936)
          08:51:16 	at hudson.model.Hudson.<init>(Hudson.java:85)
          08:51:16 	at org.jvnet.hudson.test.JenkinsRule.newHudson(JenkinsRule.java:675)
          08:51:16 	at org.jvnet.hudson.test.JenkinsRule.before(JenkinsRule.java:402)
          08:51:16 	at org.jvnet.hudson.test.JenkinsRule$1.evaluate(JenkinsRule.java:595)
          08:51:16 	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
          08:51:16 	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
          08:51:16 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
          08:51:16 	at java.lang.Thread.run(Thread.java:748)
          08:51:16 Caused by: java.io.IOException: jenkins.model.InvalidBuildsDir: ${ITEM_ROOTDIR}/builds does not resolve to an absolute path
          08:51:16 	at jenkins.model.Jenkins.loadConfig(Jenkins.java:3050)
          08:51:16 	at jenkins.model.Jenkins.access$1200(Jenkins.java:310)
          08:51:16 	at jenkins.model.Jenkins$13.run(Jenkins.java:3145)
          08:51:16 	at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:169)
          08:51:16 	at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
          08:51:16 	at jenkins.model.Jenkins$5.runTask(Jenkins.java:1095)
          08:51:16 	at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
          08:51:16 	at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
          08:51:16 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
          08:51:16 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
          08:51:16 	... 1 more
          08:51:16 Caused by: jenkins.model.InvalidBuildsDir: ${ITEM_ROOTDIR}/builds does not resolve to an absolute path
          08:51:16 	at jenkins.model.Jenkins.checkRawBuildsDir(Jenkins.java:3101)
          08:51:16 	at jenkins.model.Jenkins.loadConfig(Jenkins.java:3047)
          08:51:16 	... 10 more
          

          Kanstantsin Shautsou added a comment - - edited Now it's impossible to run Jenkins on relative dir path. If i pass into jenkins rule target/somedir it fails because Jenkins instance itself can work without issues, but this check throws and fails. Fresh Jenkins object has no config.xml in JenkinsRule, then checks {{ checkRawBuildsDir(buildsDir);}} where buildDir is "${ITEM_ROOTDIR}/builds" by default (stacktrace from 2.176.4) 08:51:16 org.jvnet.hudson.reactor.ReactorException: java.io.IOException: jenkins.model.InvalidBuildsDir: ${ITEM_ROOTDIR}/builds does not resolve to an absolute path 08:51:16 at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:282) 08:51:16 at jenkins.InitReactorRunner.run(InitReactorRunner.java:48) 08:51:16 at jenkins.model.Jenkins.executeReactor(Jenkins.java:1129) 08:51:16 at jenkins.model.Jenkins.<init>(Jenkins.java:936) 08:51:16 at hudson.model.Hudson.<init>(Hudson.java:85) 08:51:16 at org.jvnet.hudson.test.JenkinsRule.newHudson(JenkinsRule.java:675) 08:51:16 at org.jvnet.hudson.test.JenkinsRule.before(JenkinsRule.java:402) 08:51:16 at org.jvnet.hudson.test.JenkinsRule$1.evaluate(JenkinsRule.java:595) 08:51:16 at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298) 08:51:16 at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292) 08:51:16 at java.util.concurrent.FutureTask.run(FutureTask.java:266) 08:51:16 at java.lang. Thread .run( Thread .java:748) 08:51:16 Caused by: java.io.IOException: jenkins.model.InvalidBuildsDir: ${ITEM_ROOTDIR}/builds does not resolve to an absolute path 08:51:16 at jenkins.model.Jenkins.loadConfig(Jenkins.java:3050) 08:51:16 at jenkins.model.Jenkins.access$1200(Jenkins.java:310) 08:51:16 at jenkins.model.Jenkins$13.run(Jenkins.java:3145) 08:51:16 at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:169) 08:51:16 at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296) 08:51:16 at jenkins.model.Jenkins$5.runTask(Jenkins.java:1095) 08:51:16 at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214) 08:51:16 at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117) 08:51:16 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 08:51:16 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 08:51:16 ... 1 more 08:51:16 Caused by: jenkins.model.InvalidBuildsDir: ${ITEM_ROOTDIR}/builds does not resolve to an absolute path 08:51:16 at jenkins.model.Jenkins.checkRawBuildsDir(Jenkins.java:3101) 08:51:16 at jenkins.model.Jenkins.loadConfig(Jenkins.java:3047) 08:51:16 ... 10 more

          Jesse Glick added a comment -

          A relative path for $JENKINS_HOME? I would not consider that supported. Please use absolute paths only.

          Jesse Glick added a comment - A relative path for $JENKINS_HOME ? I would not consider that supported. Please use absolute paths only.

          Martin M added a comment - - edited

          batmatjglick what is the proposed solution for getting rid of this log message

          [...]
          jenkins.InitReactorRunner$1#onAttained: Completed initialization
          WARNING    j.branch.WorkspaceLocatorImpl#getWorkspaceRoot: JENKINS-2111 path sanitization ineffective when using legacy Workspace Root Directory '${ITEM_ROOTDIR}/workspace'; switch to '${JENKINS_HOME}/workspace/${ITEM_FULL_NAME}' as in JENKINS-8446 / JENKINS-21942}
          

          We have the following Docker image:

          FROM jenkins/jenkins:2.190.3
          USER root
          # Install docker dependencies
          RUN apt-get update && apt-get install --no-install-recommends -y libltdl7 && rm -rf /var/lib/apt/lists/*
          USER jenkins
          
          COPY plugins.txt /usr/share/jenkins/ref/plugins.txt
          RUN /usr/local/bin/install-plugins.sh < /usr/share/jenkins/ref/plugins.txt
          
          ENV JAVA_OPTS="-Djenkins.install.runSetupWizard=false -Dhudson.security.csrf.DefaultCrumbIssuer.EXCLUDE_SESSION_ID=true -Dhudson.model.UpdateCenter.never=true -Dhudson.slaves.WorkspaceList=_ -Dhudson.model.DirectoryBrowserSupport.CSP=\"default-src 'self'; style-src 'self' 'unsafe-inline';\""
          
          COPY init.groovy.d/*.groovy /usr/share/jenkins/ref/init.groovy.d/
          

          After running this container and running the init.d groovy scripts the log contains the above mentioned log message.

          We don't run the wizard because we configure Jenkins with some Groovy init.d scripts. What is the way to get rid of this warning?

          Appreciate your help.

          Martin M added a comment - - edited batmat jglick what is the proposed solution for getting rid of this log message [...] jenkins.InitReactorRunner$1#onAttained: Completed initialization WARNING j.branch.WorkspaceLocatorImpl#getWorkspaceRoot: JENKINS-2111 path sanitization ineffective when using legacy Workspace Root Directory '${ITEM_ROOTDIR}/workspace' ; switch to '${JENKINS_HOME}/workspace/${ITEM_FULL_NAME}' as in JENKINS-8446 / JENKINS-21942} We have the following Docker image: FROM jenkins/jenkins:2.190.3 USER root # Install docker dependencies RUN apt-get update && apt-get install --no-install-recommends -y libltdl7 && rm -rf / var /lib/apt/lists/* USER jenkins COPY plugins.txt /usr/share/jenkins/ref/plugins.txt RUN /usr/local/bin/install-plugins.sh < /usr/share/jenkins/ref/plugins.txt ENV JAVA_OPTS= "-Djenkins.install.runSetupWizard= false -Dhudson.security.csrf.DefaultCrumbIssuer.EXCLUDE_SESSION_ID= true -Dhudson.model.UpdateCenter.never= true -Dhudson.slaves.WorkspaceList=_ -Dhudson.model.DirectoryBrowserSupport.CSP=\" default -src 'self' ; style-src 'self' 'unsafe-inline' ;\"" COPY init.groovy.d/*.groovy /usr/share/jenkins/ref/init.groovy.d/ After running this container and running the init.d groovy scripts the log contains the above mentioned log message. We don't run the wizard because we configure Jenkins with some Groovy init.d scripts. What is the way to get rid of this warning? Appreciate your help.

          Jesse Glick added a comment -

          Needs core changes I think.

          Jesse Glick added a comment - Needs core changes I think.

            Unassigned Unassigned
            jglick Jesse Glick
            Votes:
            5 Vote for this issue
            Watchers:
            20 Start watching this issue

              Created:
              Updated: