[8.6.0] zipper: handle empty filelist #28425
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
updates the zipper utility so it can handle empty filelists. previously this would fail with
```
File does not seem to exist.
```
(note the double space)
rather than being treated as an empty list (`[]`), an empty filelist was being treated as a non-empty list of length one with the only element being an empty string (`['']`)
---
Why on earth do I want this? I have a rule that outputs a zip file that may or may not be empty. There is no easy way to tell ahead of time if there will be files. The output *could* be optional, but that would make my life harder for reasons that I can't be bothered explaining (feel free to push on this if it's important). `@bazel_tools//tools/zip:zipper` fails if the filelist is empty and I am working around this by manually creating an empty zip file using the EOCD record:
```js
if (files.length === 0) {
fs.writeFileSync(zipFile, '\x50\x4b\x05\x06\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00');
}
```
it would be nice if I didn't have to do this :)
Closes bazelbuild#27008.
PiperOrigin-RevId: 812683346
Change-Id: Ifb7dc35b37ce9c07e53786206e90570da542fab7
bazel-io
added
team-OSS
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request addresses an issue where the zipper utility would fail when provided with an empty filelist. The change correctly handles this case by treating an empty filelist as an empty set of files, allowing for the creation of an empty zip archive. A new test case is included to verify this behavior and prevent future regressions. While the overall approach is correct, I've identified a critical bug in the implementation that could lead to a crash due to a null pointer dereference if a memory allocation fails. Please address this issue.
meteorcloudy
approved these changes
Jan 26, 2026
Merged
via the queue into
bazelbuild:release-8.6.0
with commit Jan 26, 2026
fe199fb
47 checks passed
github-actions
bot
removed
the
awaiting-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
updates the zipper utility so it can handle empty filelists. previously this would fail with
(note the double space)
rather than being treated as an empty list (
[]), an empty filelist was being treated as a non-empty list of length one with the only element being an empty string ([''])Why on earth do I want this? I have a rule that outputs a zip file that may or may not be empty. There is no easy way to tell ahead of time if there will be files. The output could be optional, but that would make my life harder for reasons that I can't be bothered explaining (feel free to push on this if it's important).
@bazel_tools//tools/zip:zipperfails if the filelist is empty and I am working around this by manually creating an empty zip file using the EOCD record:it would be nice if I didn't have to do this :)
Closes #27008.
PiperOrigin-RevId: 812683346
Change-Id: Ifb7dc35b37ce9c07e53786206e90570da542fab7
Commit 349f6fb