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

removing a job (including multibranch/org folder branches/repos) does not remove the workspace

    • 2.0.21

      Removal of a job leaves the workspace intact.

          [JENKINS-2111] removing a job (including multibranch/org folder branches/repos) does not remove the workspace

          Jesse Glick added a comment -

          A similar report in JENKINS-54654. Please use that for discussion.

          Jesse Glick added a comment - A similar report in JENKINS-54654 . Please use that for discussion.

          Dariusz Daniłko added a comment - - edited

          jsoref: I would expect that if you specify nested 'pipeline' agent then the inner one should get a new workspace, which is why it does not have access to the git repo, which had been cloned to the workspace of the outer agent.

          You could get access to it if you `stash`ed the git repo after checkout and then `unstash`ed it in the nested pipeline stage.

          However, the pipeline does not look clean to me. What are you trying to achieve with such a nested pipeline anyway?

          Dariusz Daniłko added a comment - - edited jsoref : I would expect that if you specify nested 'pipeline' agent then the inner one should get a new workspace, which is why it does not have access to the git repo, which had been cloned to the workspace of the outer agent. You could get access to it if you `stash`ed the git repo after checkout and then `unstash`ed it in the nested pipeline stage. However, the pipeline does not look clean to me. What are you trying to achieve with such a nested pipeline anyway?

          Josh Soref added a comment -

          The nested agents do get their own git clones. The ones without a specified agent run on the same node as the main pipeline. I only need to use stash to share build products (omitted because it isn't relevant to the failure).

          Josh Soref added a comment - The nested agents do get their own git clones. The ones without a specified agent run on the same node as the main pipeline. I only need to use stash to share build products (omitted because it isn't relevant to the failure).

          David Aldrich added a comment -

          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

          It seems harmless, but how can I fix it?

          David Aldrich added a comment - 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 It seems harmless, but how can I fix it?

          Jesse Glick added a comment -

          davida2009 it is not harmless. See JENKINS-21942 esp. my last comment of 2018-04-24. Or just stop doing builds on the master.

          Jesse Glick added a comment - davida2009 it is not harmless. See JENKINS-21942 esp. my last comment of 2018-04-24. Or just stop doing builds on the master.

          David Aldrich added a comment -

          jglick Thanks for your reply. I'm afraid I'm stuck on this one. I don't understand what the console message means nor where to look in order to fix it. Please will you explain what I need to do?

          David Aldrich added a comment - jglick Thanks for your reply. I'm afraid I'm stuck on this one. I don't understand what the console message means nor where to look in order to fix it. Please will you explain what I need to do?

          Jesse Glick added a comment -

          Please ask batmat in JENKINS-21942, who was the last to work on that area.

          Jesse Glick added a comment - Please ask batmat in JENKINS-21942 , who was the last to work on that area.

          I am using Jenkins 2.204.3 and Pipeline Plugin 2.6 and this issue is clearly reproducible for me.
          I delete the job with a "Delete Pipeline" button and I see all these workspaces present on every node:

          • <workspace> itself
          • <workspace>@1,2,3...
          • <workspace>@tmp

          Should I reopen this ticket or wait for the next version of the core or plugin?

          Alexander Samoylov added a comment - I am using Jenkins 2.204.3 and Pipeline Plugin 2.6 and this issue is clearly reproducible for me. I delete the job with a "Delete Pipeline" button and I see all these workspaces present on every node: <workspace> itself <workspace>@1,2,3... <workspace>@tmp Should I reopen this ticket or wait for the next version of the core or plugin?

          Jesse Glick added a comment -

          alexander_samoylov neither. You should file a fresh issue with complete, self-contained, explicit steps to reproduce from scratch, and Link to this one. (By the way “Pipeline Plugin 2.6” is meaningless. This is just an aggregator with no code.)

          Jesse Glick added a comment - alexander_samoylov neither. You should file a fresh issue with complete, self-contained, explicit steps to reproduce from scratch, and Link to this one. (By the way “Pipeline Plugin 2.6” is meaningless. This is just an aggregator with no code.)

          Paul "TBBle" Hampson added a comment - - edited

          I just came across the warning referring to this ticket, on a Jenkins deployment with no executors on the Jenkins node (which should not happen).

          > JENKINS-2111 path sanitization ineffective when using legacy Workspace Root Directory

          There are actually two possible sources of this warning in the Branch API Plugin itself, checked on v2.6.2.

          If the message is immediately followed (assuming you have FINE logging visible, otherwise you won't see it) by
          > no available workspace root for hudson.model.Hudson@...

          then it's come from a call to locate, which will happen when a job is deleted or renamed, as the Deleter runs a task on each node (jenkins.getNodes()), which will trigger a call to locate for the Jenkins node, which hits this warning, returns null, and is ignored.

          If no such message followed the warning (and you have FINE logging visible), then it might have come from Collector reacting to the Jenkins node coming online and calling getWorkspaceRoot directly, which will again return null and be ignored.

          This warning means it won't clean up orphaned/renamed workspaces on the Jenkins node, but if you have no executor there, then you shouldn't have any to clean up anyway.

          Edit: I just noticed that JENKINS-60451 was logged for exactly this.

          Paul "TBBle" Hampson added a comment - - edited I just came across the warning referring to this ticket, on a Jenkins deployment with no executors on the Jenkins node ( which should not happen ). > JENKINS-2111 path sanitization ineffective when using legacy Workspace Root Directory There are actually two possible sources of this warning in the Branch API Plugin itself, checked on v2.6.2 . If the message is immediately followed (assuming you have FINE logging visible, otherwise you won't see it) by > no available workspace root for hudson.model.Hudson@... then it's come from a call to locate , which will happen when a job is deleted or renamed, as the Deleter runs a task on each node ( jenkins.getNodes() ), which will trigger a call to locate for the Jenkins node, which hits this warning, returns null , and is ignored. If no such message followed the warning (and you have FINE logging visible), then it might have come from Collector reacting to the Jenkins node coming online and calling getWorkspaceRoot directly, which will again return null and be ignored. This warning means it won't clean up orphaned/renamed workspaces on the Jenkins node, but if you have no executor there, then you shouldn't have any to clean up anyway. Edit: I just noticed that JENKINS-60451 was logged for exactly this.

            jglick Jesse Glick
            bll6969 bll
            Votes:
            90 Vote for this issue
            Watchers:
            101 Start watching this issue

              Created:
              Updated:
              Resolved: