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

[jenkins-infra-bot]

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

---

Originally reported by jameshowe, imported from: Zip artifact downloads missing a top-level directory

• assignee: wfollonier
• status: Closed
• priority: Major
• component(s): core
• label(s): 2.263.3-fixed, regression, security-1452
• resolution: Fixed
• resolved: 2021-01-19T13:04:15+00:00
• votes: 2
• watchers: 9
• imported: 2025-11-24

Raw content of original issue

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

• environment: Jenkins LTS 2.263.2

[jenkins-infra-bot]

• Remote link associated with this issue:

  • #​5187 in core

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  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.
  

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.

[jenkins-infra-bot]

danielbeck:

• Original comment link
• Raw content of original comment:

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

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

 

[jenkins-infra-bot]

wfollonier:

• Original comment link
• Raw content of original 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.
  

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.

[jenkins-infra-bot]

jameshowe:

• Original comment link
• Raw content of original comment:

  Is there a estimated release date for 2.263.3?
  

Is there a estimated release date for 2.263.3?

[jenkins-infra-bot]

wfollonier:

• Original comment link
• Raw content of original 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: [JENKINS-64621] Fix zip regression #5187
  

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: #5187

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  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.
  

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.

[jenkins-infra-bot]

grayaii:

• Original comment link
• Raw content of original 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!)
  

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!)

[jenkins-infra-bot]

njesper:

• Original comment link
• Raw content of original 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.)
  

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

[jenkins-infra-bot]

grayaii:

• Original comment link
• Raw content of original 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.
  

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.

[jenkins-infra-bot]

mwils2424:

• Original comment link
• Raw content of original 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. 
  

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. 

[jenkins-infra-bot]

[Original relates_to from Jira: JENKINS-61473]