Build: Preserve plugin ZIP modified time when contents are unchanged - #2566
Merged
Conversation
`build-plugins:zip` rebuilds each plugin archive from a freshly re-copied build directory, so the `zip` command embeds new entry timestamps every run and the resulting bytes always differ even when the file contents are identical. This bumped the ZIP's modified time on every build regardless of whether anything actually changed. Build the archive into a temporary file and compare it against the existing ZIP using a timestamp-independent content fingerprint (each entry's uncompressed size, CRC-32, and name via `unzip -v`). The existing ZIP is only replaced when its contents actually change; otherwise the temporary file is discarded and the existing file — including its modified time — is left untouched. Building fresh into a temporary file each time also ensures files removed from a plugin no longer linger in an updated-in-place archive. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
westonruter
added
[Type] Enhancement
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
Summary
Make
build-plugins:zipleave an existing plugin ZIP file — and its modified time — untouched when a rebuild produces identical contents. The modified time now only changes when the ZIP's contents actually change.Personal note: This will help a lot with obtaining ZIP builds to share with others during pre-release testing. When sorting files in a directory by modified date, running
npm run build-plugins:zipwill always cause the actually modified plugins' ZIP files to appear at the top of the list. They can then be easily attached to a PR as a comment, for example in #2565 (comment).Relevant technical choices
build-plugins:ziprebuilds each plugin archive from a freshly re-copied build directory, so thezipcommand embeds new entry timestamps on every run. As a result the resulting archive bytes always differ even when the file contents are byte-for-byte identical, and every build bumped the ZIP's modified time regardless of whether anything actually changed. Comparing the raw archive bytes therefore can't detect "no change."Instead,
createPluginZip()now:<plugin>.zip.tmp) rather than directly over the existing ZIP.getZipContentFingerprint()helper, which runsunzip -vand keeps each entry's uncompressed size + CRC-32 + name, deliberately dropping the date/time columns — a timestamp-independent content fingerprint.A side benefit: because each build now starts from a fresh temporary archive rather than updating the existing ZIP in place, files removed from a plugin no longer linger as stale entries (the previous
zip -rover an existing archive only added/updated entries, never removed them).Verified manually:
.tmpfiles;zipfailures still throw (with temp cleanup).Use of AI Tools
This PR was authored with the assistance of Claude Code (Opus 4.8). The approach, implementation, and commit/PR text were AI-generated based on my direction, and I reviewed and verified the changes (including the manual build tests above).
🤖 Generated with Claude Code