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

A recent update breaks builds by escaping slashes to percent signs in workspace paths

    XMLWordPrintable

    Details

    • Similar Issues:
    • Released As:
      2.1.2

      Description

      After a recent update, slashes in git branches (e.g. bugfix/branch-description) are escaped into workspace path names using %2F, as in wkspacepath/bugfix%2Fbranch-description. This breaks the build on my windows machine. The slashes used to be translated to underscores.

        Attachments

          Issue Links

            Activity

            Hide
            godskalk Øyvind R added a comment -

            Same update caused JENKINS-54640

            Show
            godskalk Øyvind R added a comment - Same update caused JENKINS-54640
            Hide
            jglick Jesse Glick added a comment -

            Please follow the diagnostic instructions given in JENKINS-2111.

            Show
            jglick Jesse Glick added a comment - Please follow the diagnostic instructions given in JENKINS-2111 .
            Hide
            godskalk Øyvind R added a comment -

            Thanks Jesse Glick. JENKINS 2111 has a very long thread, and I'm not sure which instructions you are talking about. If it's about adding -Djenkins.branch.WorkspaceLocatorImpl.MODE=ENABLED, I tried this with no luck.

            Show
            godskalk Øyvind R added a comment - Thanks Jesse Glick . JENKINS 2111 has a very long thread, and I'm not sure which instructions you are talking about. If it's about adding -Djenkins.branch.WorkspaceLocatorImpl.MODE=ENABLED, I tried this with no luck.
            Hide
            jglick Jesse Glick added a comment -

            Øyvind R sorry, I should have repeated the critical bit: install this build and create a logger (Manage Jenkins » System Log) on jenkins.branch.WorkspaceLocatorImpl recording at least FINER and check for messages there when you build a branch project for the first time on a given agent. Also check whether …\workspaceroot\workspaces.txt exists and, if so, what it contains.

            It is helpful to install the Support Core plugin (optionally enabling anonymization) and capturing a bundle after observing the problem, either attaching it here after review for sensitive information or mailing it to jglick-at-cloudbees.com directly, as that will capture the full custom logger output very readably and also indicate whether there are other log warnings, unusual configuration elements, etc. that could point to the problem.

            Show
            jglick Jesse Glick added a comment - Øyvind R sorry, I should have repeated the critical bit: install this build and create a logger ( Manage Jenkins » System Log ) on jenkins.branch.WorkspaceLocatorImpl recording at least FINER and check for messages there when you build a branch project for the first time on a given agent. Also check whether …\workspaceroot\workspaces.txt exists and, if so, what it contains. It is helpful to install the Support Core plugin (optionally enabling anonymization) and capturing a bundle after observing the problem, either attaching it here after review for sensitive information or mailing it to jglick-at-cloudbees.com directly, as that will capture the full custom logger output very readably and also indicate whether there are other log warnings, unusual configuration elements, etc. that could point to the problem.
            Hide
            smorley Stephen Morley added a comment -

            This problem appeared after I did an upgrade. I tried to restore to previous version and plugins but problem persisted. I enabled a log as noted above and found a message: JENKINS-2111 path sanitization ineffective when using legacy workspace root directory c:\JenkinsWorkspace\${ITEM_FULLNAME}; switch to ${JENKINS_HOME}/workspace/${ITEM_FULLNAME}

            so I did and its working now!

            This did move to a new workplace so all the directories are now so I don't know if that fixed it or the form of the path. Note the slashes were reversed. Before this Jenkins was creating a working directory simply with the first part of the name , e.g. QA/V2018 became QA

            Show
            smorley Stephen Morley added a comment - This problem appeared after I did an upgrade. I tried to restore to previous version and plugins but problem persisted. I enabled a log as noted above and found a message: JENKINS-2111 path sanitization ineffective when using legacy workspace root directory c:\JenkinsWorkspace\${ITEM_FULLNAME}; switch to ${JENKINS_HOME}/workspace/${ITEM_FULLNAME} so I did and its working now! This did move to a new workplace so all the directories are now so I don't know if that fixed it or the form of the path. Note the slashes were reversed. Before this Jenkins was creating a working directory simply with the first part of the name , e.g. QA/V2018 became QA
            Hide
            jglick Jesse Glick added a comment -

            Stephen Morley you may have hit JENKINS-21942. Note that this only affects builds run on the master, not on agents.

            Show
            jglick Jesse Glick added a comment - Stephen Morley you may have hit JENKINS-21942 . Note that this only affects builds run on the master, not on agents.
            Hide
            smorley Stephen Morley added a comment -

            Jesse Glick that might explain why the setting was not updated but why is it not valid to reference a directory outside of the JENKINS_HOME. Personally I don't like keeping active data sets in the "Program Files (x86)" directory. This has worked for over 5 years now and suddenly it fails. (Turns out we also have a problem with some utility which is not working with the spaces in the path name so our builds are broken using this form but without it Jenkins just chokes).

            Show
            smorley Stephen Morley added a comment - Jesse Glick that might explain why the setting was not updated but why is it not valid to reference a directory outside of the JENKINS_HOME. Personally I don't like keeping active data sets in the "Program Files (x86)" directory. This has worked for over 5 years now and suddenly it fails. (Turns out we also have a problem with some utility which is not working with the spaces in the path name so our builds are broken using this form but without it Jenkins just chokes).
            Hide
            jglick Jesse Glick added a comment -

            Actually that warning was really intended for the broken old default ${ITEM_ROOTDIR}/workspace. Customized roots ending in …/${ITEM_FULLNAME} (or …/${ITEM_FULL_NAME}) should be supportable with the new managed layout. Again note that this only pertains to master-based builds; using agents is recommended.

            Show
            jglick Jesse Glick added a comment - Actually that warning was really intended for the broken old default ${ITEM_ROOTDIR}/workspace . Customized roots ending in …/${ITEM_FULLNAME } (or …/${ITEM_FULL_NAME }) should be supportable with the new managed layout. Again note that this only pertains to master-based builds; using agents is recommended.
            Hide
            jglick Jesse Glick added a comment -

            PR 137 should fix the issue discovered by Stephen Morley. I never got diagnostics from the original reporter Øyvind R so hard to know if that issue was the same or unrelated.

            Show
            jglick Jesse Glick added a comment - PR 137 should fix the issue discovered by Stephen Morley . I never got diagnostics from the original reporter Øyvind R so hard to know if that issue was the same or unrelated.
            Hide
            phkoc Philippe Kocher added a comment -

            Deat Community,

            I'm facing the same problem with my multibranch pipeline project: "feature/branch" from a git repository is transformed to "feature%2Fbranch" which causes build to fail because the build process cannot find the files. As mentionned above, I did an update of Jenkins and the branch API plugin but the problem is still remaining.

             

            I'm working with:

            Jenkins version 2.190.3

            Branch API Plugin Version 2.5.5

            I saw tat PR#137 should solve the problem. Is this PR already merged, i.e. available in the latest release of Jenkins Branch API Plugin available? If yes, I think that the issue is still active and not resolved.

            Any update about this issue?

            Find also attached to this message two screenshot conerning the issue: the Branch name on git and the result on the Jenkins Workspace.

             

            Show
            phkoc Philippe Kocher added a comment - Deat Community, I'm facing the same problem with my multibranch pipeline project: "feature/branch" from a git repository is transformed to "feature%2Fbranch" which causes build to fail because the build process cannot find the files. As mentionned above, I did an update of Jenkins and the branch API plugin but the problem is still remaining.   I'm working with: Jenkins version 2.190.3 Branch API Plugin Version 2.5.5 I saw tat PR#137 should solve the problem. Is this PR already merged, i.e. available in the latest release of Jenkins Branch API Plugin available? If yes, I think that the issue is still active and not resolved. Any update about this issue? Find also attached to this message two screenshot conerning the issue: the Branch name on git and the result on the Jenkins Workspace.  
            Hide
            jhuels Josh Huels added a comment -

            Also seeing the same issue as Philippe Kocher.  This is occurring on a Jenkins Agent running multi-branch pipelines.

             

             
            Jenkins ver. 2.190.2

             Branch API Plugin 2.1.2

             

            From reading all of these other tickets, the steps to debug only relate to running builds from master.  This is occurring for me from agents.

            On the agent, `println jenkins.branch.WorkspaceLocatorImpl.PATH_MAX` returns 80.

            `println jenkins.branch.WorkspaceLocatorImpl.MODE` returns MULTIBRANCH_ONLY.

             

            Show
            jhuels Josh Huels added a comment - Also seeing the same issue as Philippe Kocher.  This is occurring on a Jenkins Agent running multi-branch pipelines.     Jenkins ver. 2.190.2  Branch API Plugin 2.1.2   From reading all of these other tickets, the steps to debug only relate to running builds from master.  This is occurring for me from agents. On the agent, `println jenkins.branch.WorkspaceLocatorImpl.PATH_MAX` returns 80. `println jenkins.branch.WorkspaceLocatorImpl.MODE` returns MULTIBRANCH_ONLY.  
            Hide
            jrichards Jeff Richards added a comment -

            I also had this problem.  

            In my case, I was running jenkins in a linux environment, Jenkins version 2.190.3 Branch API Plugin Version 2.5.5.  This is a multibranch pipeline buidl environment with agents doing the building. In my case interestingly this was only happening on 1 of three nodes (it took me hours to figure THAT out).

            After much searching what I found was that when I reviewed the node log for the failing node (Manage Jenkins -> Manage Nodes -> click on node in question -> Log, I found that the /home/jenkins/workspace/workspace.txt file was noted as being corrupt.  For whatever reason this meant that when the build was attempted on that node, the build directory was not the usual workspace directory (which has all branch name slashes (encoded as %2F) cases  replaced with underscores).

            In my case, I just creaed a new workspace.txt file and then disconnected and reconnected the node.  And... things started working again.

            So, if you're experiencing this, review the node logs.  

            As a suggestion for improving jenkins, I would suggest that if the workspaces.txt file is corrupt, the node should be taken offline.  At least then the admin has a clue that this is a node based issue, and that the node needs manual intervention for things to get back to normal.

             

            Show
            jrichards Jeff Richards added a comment - I also had this problem.   In my case, I was running jenkins in a linux environment, Jenkins version 2.190.3 Branch API Plugin Version 2.5.5.  This is a multibranch pipeline buidl environment with agents doing the building. In my case interestingly this was only happening on 1 of three nodes (it took me hours to figure THAT out). After much searching what I found was that when I reviewed the node log for the failing node (Manage Jenkins -> Manage Nodes -> click on node in question -> Log, I found that the /home/jenkins/workspace/workspace.txt file was noted as being corrupt.  For whatever reason this meant that when the build was attempted on that node, the build directory was not the usual workspace directory (which has all branch name slashes (encoded as %2F) cases  replaced with underscores). In my case, I just creaed a new workspace.txt file and then disconnected and reconnected the node.  And... things started working again. So, if you're experiencing this, review the node logs.   As a suggestion for improving jenkins, I would suggest that if the workspaces.txt file is corrupt, the node should be taken offline.  At least then the admin has a clue that this is a node based issue, and that the node needs manual intervention for things to get back to normal.  
            Hide
            jglick Jesse Glick added a comment -

            I would suggest that if the workspaces.txt file is corrupt, the node should be taken offline.

            Better to file this as an Enhancement with label robustness in this component and Link to this issue.

            Of course better would be to automatically correct a corrupted file, and better still would be to figure out what corrupted it to begin with. What did the supposedly corrupt file contain? Any known steps to reproduce? Etc.

            Show
            jglick Jesse Glick added a comment - I would suggest that if the workspaces.txt file is corrupt, the node should be taken offline. Better to file this as an Enhancement with label robustness in this component and Link to this issue. Of course better would be to automatically correct a corrupted file, and better still would be to figure out what corrupted it to begin with. What did the supposedly corrupt file contain? Any known steps to reproduce? Etc.
            Hide
            jrichards Jeff Richards added a comment -

            Jesse Glick, thanks for the pointer, created JENKINS-60785

            Show
            jrichards Jeff Richards added a comment - Jesse Glick , thanks for the pointer, created  JENKINS-60785

              People

              Assignee:
              jglick Jesse Glick
              Reporter:
              godskalk Øyvind R
              Votes:
              2 Vote for this issue
              Watchers:
              15 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: