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

userContent *zip* (all files in zip) stopped working at 2.164

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • core
    • Windows 2008 R2 Enterprise, Jenkins 2.164+

      When using the (all files in zip) functionality starting at 2.164, either from the UI or URL (https:/myjenkins/userContent/*zip*/image.zip), the resulting image.zip has no content. 

      This has silently broken our builds, which utilize this functionality to retrieve certain content. Downgrading jenkins.war to 2.163 restores the functionality.

          [JENKINS-56249] userContent *zip* (all files in zip) stopped working at 2.164

          Glenn Herbert created issue -
          Glenn Herbert made changes -
          Description Original: When using the (all files in zip) functionality starting at 2.164, either from the UI or URL (https:/myjenkins/userContent/*zip*/image.zip), the resulting image.zip has no content. 

          This has silently broken our builds, which utilize this functionality to retrieve certain content. Downgrading jenkins.war to 2.163 restores the functionality.
          New: When using the (all files in zip) functionality starting at 2.164, either from the UI or URL (https:/myjenkins/userContent/**zip**/image.zip), the resulting image.zip has no content. 

          This has silently broken our builds, which utilize this functionality to retrieve certain content. Downgrading jenkins.war to 2.163 restores the functionality.

          Daniel Beck added a comment -

          Daniel Beck added a comment - wfollonier FYI

          kansasmann Thank you for the report.

          I will not have the time to investigate this case further this week.

          Could you try using the WAR provided in JENKINS-56114 ? As they were also using Windows Server, that could the same root cause.

          In addition, did you try with the escape hatch: java.exe -Dhudson.model.DirectoryBrowserSupport.allowSymlinkEscape=true -jar jenkins.war ? (in both your current version and in the WAR provided in the other ticket)

          Then could you give me more information about your configuration, like are you using Docker inside your Windows Server, or just running java -jar ..., or using the service?

          If you can provide also additional information from the log of the build, that could be useful. Also, what is the content of the userContent in your instance (in terms of type, not the real files, but to know if there are symlinks, what are their targets, or just image files?)

          Thank you in advance for your next answer that will help me helping you

          Wadeck Follonier added a comment - kansasmann Thank you for the report. I will not have the time to investigate this case further this week. Could you try using the WAR provided in JENKINS-56114 ? As they were also using Windows Server, that could the same root cause. In addition, did you try with the escape hatch: java.exe -Dhudson.model.DirectoryBrowserSupport.allowSymlinkEscape=true -jar jenkins.war ? (in both your current version and in the WAR provided in the other ticket) Then could you give me more information about your configuration, like are you using Docker inside your Windows Server, or just running java -jar ... , or using the service? If you can provide also additional information from the log of the build, that could be useful. Also, what is the content of the userContent in your instance (in terms of type, not the real files, but to know if there are symlinks, what are their targets, or just image files?) Thank you in advance for your next answer that will help me helping you
          Glenn Herbert made changes -
          Attachment New: image-2019-02-28-16-52-19-863.png [ 46219 ]
          Glenn Herbert made changes -
          Attachment New: image-2019-02-28-16-53-48-739.png [ 46220 ]
          Glenn Herbert made changes -
          Attachment New: image-2019-02-28-16-54-36-484.png [ 46221 ]
          Glenn Herbert made changes -
          Attachment New: image-2019-02-28-16-55-40-767.png [ 46222 ]

          Glenn Herbert added a comment - - edited

          Wadeck Follonier: I cannot try using the WAR from JENKINS-56114  as this is a production system.  I will try to bring up a new jenkins and try it.
          To answer your other questions:

          • we are using the escape hatch -Dhudson.model.DirectoryBrowserSupport.allowSymlinkEscape=true
          • we are NOT using docker, just running the jenkins windows service
          • userContent has a mix of files, folders, and directory junctions (symlinks)

          The build logs have no real information in them as it was a silent failure, because the zip was empty.  The gradle code used was

          def f = new File("$buildOutput/staging.zip")
          if (!f.exists()) {
               new URL('http://myJenkins:8080/userContent/archive/components/Staging/*zip*/staging.zip').withInputStream{ i -> f.withOutputStream{ it << i }}
          }
          copy
          Unknown macro: {     from zipTree(f.getAbsolutePath())      into("$buildOutput/config/") }
          f.delete()

          From the UI, this is the Staging folder (this is not the actual folder used but shows the problem):

          If i then click on the (all files in zip), the Staging.zip file gets generated but its only 1KB

          And if its opened with 7zip the file is empty

          If I dump the file using od -c i see no content

          Hope this additional information helps!

           

          Glenn Herbert added a comment - - edited Wadeck Follonier: I cannot try using the WAR from JENKINS-56114   as this is a production system.  I will try to bring up a new jenkins and try it. To answer your other questions: we are using the escape hatch -Dhudson.model.DirectoryBrowserSupport.allowSymlinkEscape=true we are NOT using docker, just running the jenkins windows service userContent has a mix of files, folders, and directory junctions (symlinks) The build logs have no real information in them as it was a silent failure, because the zip was empty.  The gradle code used was def f = new File("$buildOutput/staging.zip") if (!f.exists()) {      new URL('http://myJenkins:8080/userContent/archive/components/Staging/* zip */staging.zip').withInputStream{ i -> f.withOutputStream{ it << i }} } copy Unknown macro: {     from zipTree(f.getAbsolutePath())      into("$buildOutput/config/") } f.delete() From the UI, this is the Staging folder (this is not the actual folder used but shows the problem): If i then click on the (all files in zip), the Staging.zip file gets generated but its only 1KB And if its opened with 7zip the file is empty If I dump the file using od -c i see no content Hope this additional information helps!  

          Daniel Beck added a comment -

          Is this obsolete after recent changes in weekly releases?

          Daniel Beck added a comment - Is this obsolete after recent changes in weekly releases?

            Unassigned Unassigned
            kansasmann Glenn Herbert
            Votes:
            2 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated: