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

Zip artifact downloads missing a top-level directory

    • 2.276 and 2.263.3

      Upgrading from 2.263.1 to 2.263.2 has this undocumented change.
      Zip files of artifacts no longer have a top-level directory, but all the contents at the root.

      Examples:

      • $BUILD_URL/artifact/target/*zip*/target.zip
      • $BUILD_URL/artifact/dist/Release/*zip*/Release.zip
      • $BUILD_URL/Documentation/*zip*/Documentation.zip

      Possible regression of JENKINS-19947

          [JENKINS-64621] Zip artifact downloads missing a top-level directory

          Mark Waite added a comment - - edited

          I've confirmed that there is a behavioral change from 2.263.1 to 2.263.2 as described. Thanks for the report.

          The test job that I created is stored in the lts-with-plugins branch of my docker-lfs repository.

          When that job is run with Jenkins 2.263.1, it passes and reports the zip archive contents are all under a directory named 'archive/src'.

          When that job is run with Jenkins 2.263.2, it is unstable and reports the zip archive contents are all under a directory named 'src' (no top level directory named 'archive').

          I assume the change is a side effect of one of the security fixes.

          Mark Waite added a comment - - edited I've confirmed that there is a behavioral change from 2.263.1 to 2.263.2 as described. Thanks for the report. The test job that I created is stored in the lts-with-plugins branch of my docker-lfs repository . When that job is run with Jenkins 2.263.1, it passes and reports the zip archive contents are all under a directory named 'archive/src'. When that job is run with Jenkins 2.263.2, it is unstable and reports the zip archive contents are all under a directory named 'src' (no top level directory named 'archive'). I assume the change is a side effect of one of the security fixes.

          Daniel Beck added a comment - - edited

          JENKINS-19947 was a similar problem a few years ago. We should really have tests for zip structure

           

          Daniel Beck added a comment - - edited JENKINS-19947 was a similar problem a few years ago. We should really have tests for zip structure  

          Thanks for the jameshowe, a PR with the fix will be provided soon-ish so that you can review/test it if you want and will ultimately delivered in 2.263.3 as a regression correction.

          Wadeck Follonier added a comment - Thanks for the jameshowe , a PR with the fix will be provided soon-ish so that you can review/test it if you want and will ultimately delivered in 2.263.3 as a regression correction.

          James Howe added a comment -

          Is there a estimated release date for 2.263.3?

          James Howe added a comment - Is there a estimated release date for 2.263.3?

          jameshowe Not yet. This regression alone does not seem sufficiently important to justify an out-of-order LTS version. Please change my mind

          If there is not expedite of out-of-order, the next LTS should be in ~3 weeks (one every month).


          The promised PR: https://github.com/jenkinsci/jenkins/pull/5187

          Wadeck Follonier added a comment - jameshowe Not yet. This regression alone does not seem sufficiently important to justify an out-of-order LTS version. Please change my mind If there is not expedite of out-of-order, the next LTS should be in ~3 weeks (one every month). The promised PR: https://github.com/jenkinsci/jenkins/pull/5187

          Mark Waite added a comment - - edited

          jameshowe I built a local copy of the Jenkins master branch with pull request 5187 and confirmed that it passes the job that was consistently failing on Jenkins 2.275 and Jenkins 2.263.2. You're welcome to use my build to test or you can use the ci.jenkins.io build that will be generated as part of the pull request.

          Mark Waite added a comment - - edited jameshowe I built a local copy of the Jenkins master branch with pull request 5187 and confirmed that it passes the job that was consistently failing on Jenkins 2.275 and Jenkins 2.263.2. You're welcome to use my build to test or you can use the ci.jenkins.io build that will be generated as part of the pull request.

          Alex Gray added a comment -

          Oh wow. Thank you markewaite for the quick turnaround! This is a show stopper for us (we have custom scripts that look on these artifacts).  Can't wait for this to be in a TLS (We are only allowed to use TLS versions). (And thank you Oleg for verifying the PR works!)

          Alex Gray added a comment - Oh wow. Thank you markewaite  for the quick turnaround! This is a show stopper for us (we have custom scripts that look on these artifacts).  Can't wait for this to be in a TLS (We are only allowed to use TLS versions). (And thank you Oleg for verifying the PR works!)

          grayaii, if you are doing automatic downloading of artifacts you should probably have a look at JENKINS-64669 that I just filed. Normal "occasional" downloads might not be enough to trigger problems, but high frequency automated downloads was what triggered it for us. (And zip-on-the-fly downloads might not be affected - I've not investigated that.)

          Jesper Andersson added a comment - grayaii , if you are doing automatic downloading of artifacts you should probably have a look at  JENKINS-64669 that I just filed. Normal "occasional" downloads might not be enough to trigger problems, but high frequency automated downloads was what triggered it for us. (And zip-on-the-fly downloads might not be affected - I've not investigated that.)

          Alex Gray added a comment -

          Ouchie. Yeah, that a big one.  We use datadog to monitor open file handles, but I didn't even get that far due to this ticket.
          Wow.  Thank you so much for pointing that out.  I just voted for that ticket too. You just saved us a ton of headahe.

          Alex Gray added a comment - Ouchie. Yeah, that a big one.  We use datadog to monitor open file handles, but I didn't even get that far due to this ticket. Wow.  Thank you so much for pointing that out.  I just voted for that ticket too. You just saved us a ton of headahe.

          Matt Wilson added a comment -

          Thanks njesper we've run into that issue the past couple of nights after upgrading this weekend.  Upped our limits last night, but good to know we need to keep an eye on this. 

          Matt Wilson added a comment - Thanks njesper  we've run into that issue the past couple of nights after upgrading this weekend.  Upped our limits last night, but good to know we need to keep an eye on this. 

            wfollonier Wadeck Follonier
            jameshowe James Howe
            Votes:
            2 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved: