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

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

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • branch-api-plugin
    • None
    • Windows
    • 2.1.2

      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.

          [JENKINS-54654] A recent update breaks builds by escaping slashes to percent signs in workspace paths

          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

          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

          Jesse Glick added a comment -

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

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

          jglick 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).

          Stephen Morley added a comment - jglick 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).

          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.

          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.

          Jesse Glick added a comment -

          PR 137 should fix the issue discovered by smorley. I never got diagnostics from the original reporter godskalk so hard to know if that issue was the same or unrelated.

          Jesse Glick added a comment - PR 137 should fix the issue discovered by smorley . I never got diagnostics from the original reporter godskalk so hard to know if that issue was the same or unrelated.

          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.

           

          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.  

          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.

           

          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.  

          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.

           

          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.  

          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.

          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.

          Jeff Richards added a comment -

          jglick, thanks for the pointer, created JENKINS-60785

          Jeff Richards added a comment - jglick , thanks for the pointer, created  JENKINS-60785

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

              Created:
              Updated:
              Resolved: