Skip to content

Fix doubly-zipped plugin artifacts in GitHub Actions#76857

Draft
Copilot wants to merge 3 commits intotrunkfrom
copilot/remove-double-zipping-artifacts
Draft

Fix doubly-zipped plugin artifacts in GitHub Actions#76857
Copilot wants to merge 3 commits intotrunkfrom
copilot/remove-double-zipping-artifacts

Conversation

Copy link
Copy Markdown
Contributor

Copilot AI commented Mar 27, 2026

What?

Fixes the double-zipping of the Gutenberg plugin artifact in GitHub Actions. When gutenberg.zip was uploaded, it got re-wrapped in another ZIP by the upload action, requiring users to unzip twice before they could install the plugin.

Why?

GitHub Actions' actions/upload-artifact automatically archives uploaded files into a ZIP, so uploading an existing .zip results in a double-zipped file. Users downloading the artifact from the workflow run page get a ZIP containing a ZIP, and attempting to install it directly in WordPress fails.

actions/upload-artifact@v7.0.0 (already pinned in this repo) introduced archive: false to upload a single file as-is, without re-wrapping it. This PR uses that option for the Gutenberg plugin build only.

The wordpress-develop build artifact (gutenberg-wordpress-develop) is only used internally — consumed by the publish-to-container-registry job in the same workflow, which unzips it and re-compresses to GHCR — so it continues to work with its existing behavior unchanged.

How?

The single shared upload step in build-plugin-zip.yml is split into two conditional steps:

  • Plugin build (IS_GUTENBERG_PLUGIN: true): Uses archive: false so the artifact is the raw gutenberg.zip, ready to install in WordPress. The artifact name becomes gutenberg.zip (the name input is ignored by the action when archive: false).
  • WordPress develop build (IS_GUTENBERG_PLUGIN: false): Keeps the original behavior with name: gutenberg-wordpress-develop. No changes to the publish-to-container-registry job.

The create-release job is updated to download the artifact named gutenberg.zip (previously gutenberg-plugin).

Note

The artifact name changes from gutenberg-plugin to gutenberg.zip. This is an unavoidable consequence of using archive: false — the action's documentation explicitly states the name parameter is ignored in that mode and the filename is always used as the artifact name.

Testing Instructions

  1. Trigger the Build Plugin ZIP workflow on this branch (or wait for CI to run on this PR).
  2. Go to the completed workflow run and download the artifact named gutenberg.zip.
  3. Go to WordPress Playground (or any WordPress install).
  4. Navigate to Plugins → Add New → Upload Plugin and upload the downloaded gutenberg.zip.
  5. Verify that the plugin installs successfully — "Plugin installed successfully." — without a "No valid plugins were found" error.

Testing Instructions for Keyboard

N/A — this is a CI/workflow-only change with no UI impact.

Screenshots or screencast

Before After
Before: plugin installation fails with "No valid plugins were found" because the artifact was double-zipped After: plugin installs successfully — "Plugin installed successfully."

Use of AI Tools

This PR was authored with GitHub Copilot (Coding Agent).


💬 Send tasks to Copilot coding agent from Slack and Teams to turn conversations into code. Copilot posts an update in your thread when it's finished.

Copilot AI changed the title [WIP] Fix double zipping of plugin ZIP files in GitHub Actions Fix doubly-zipped plugin artifacts in GitHub Actions Mar 27, 2026
Copilot AI requested a review from luisherranz March 27, 2026 09:13
Comment on lines +225 to +236
- name: Rename artifact for wordpress-develop build
if: ${{ ! matrix.IS_GUTENBERG_PLUGIN }}
run: mv gutenberg.zip gutenberg-wordpress-develop.zip

- name: Upload artifact
uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
with:
name: gutenberg-${{ ! matrix.IS_GUTENBERG_PLUGIN && 'wordpress-develop' || 'plugin' }}
path: ./gutenberg.zip
# When archive is false, the file name is used as the artifact name.
# gutenberg.zip -> artifact "gutenberg.zip" (plugin build)
# gutenberg-wordpress-develop.zip -> artifact "gutenberg-wordpress-develop.zip" (WP develop build)
path: ${{ ! matrix.IS_GUTENBERG_PLUGIN && './gutenberg-wordpress-develop.zip' || './gutenberg.zip' }}
archive: false
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@copilot, investigate and report what exactly is the zip for the WordPress develop build used for? Is it used in this repository, or in the wordpress-develop repository?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The gutenberg-wordpress-develop.zip artifact is used only within this repository's workflow, as an internal intermediate step.

Here's the full flow:

  1. The build job (with IS_GUTENBERG_PLUGIN: false) builds a WordPress-core-targeted version of the assets (with wpPlugin.name = "wp" and IS_WORDPRESS_CORE: true) and produces gutenberg.zip.
  2. That ZIP is uploaded as the gutenberg-wordpress-develop.zip artifact.
  3. The publish-to-container-registry job (which also lives in this same workflow file) downloads that artifact, unzips it, re-compresses the files as a .tar.gz, and pushes the result to GitHub Container Registry at ghcr.io/wordpress/gutenberg/gutenberg-wp-develop-build:<sha>.

The wordpress-develop repository doesn't consume the Actions artifact directly — it uses the GHCR tar.gz package produced in step 3. The ZIP artifact itself is never downloaded externally; it's purely an internal hand-off mechanism between the build job and the publish-to-container-registry job within this same workflow run.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@copilot, are the changes in that part of the workflows absolutely necessary if that is internal? Can't this continue to function with a double zip as it has been working until now?

I'm only interested in the final gutenberg.zip.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point — the wordpress-develop build side doesn't need the fix. Updated in c6dc156:

  • The single shared upload step is now split into two conditional steps: the plugin build uses archive: false, and the wordpress-develop build reverts to the original name: gutenberg-wordpress-develop behavior (double-zip intact, publish-to-container-registry fully reverted).
  • The "Rename artifact" step is removed entirely.
  • The only remaining change from the original is: plugin build uses archive: false (fixing the double-zip for users) + create-release downloads name: gutenberg.zip (the artifact name set by archive: false).

…nal as-is

Agent-Logs-Url: https://github.com/WordPress/gutenberg/sessions/d65f3bcc-6af7-46c5-ab37-83c5ebe9d094

Co-authored-by: luisherranz <3305402+luisherranz@users.noreply.github.com>
@github-actions
Copy link
Copy Markdown

Flaky tests detected in c6dc156.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/23640506904
📝 Reported issues:

@luisherranz
Copy link
Copy Markdown
Member

@copilot, the artifact name has changed from gutenberg-plugin to gutenberg.zip. Is this unavoidable, or can the same artifact name be kept to prevent breaking environments that are integrating this file?

Copy link
Copy Markdown
Contributor Author

Copilot AI commented Mar 27, 2026

@copilot, the artifact name has changed from gutenberg-plugin to gutenberg.zip. Is this unavoidable, or can the same artifact name be kept to prevent breaking environments that a...

It's unavoidable when using archive: false. The action.yml explicitly documents this behavior:

When archive is false, only a single file can be uploaded. The name of the file will be used as the artifact name (ignoring the name parameter).

The only workaround is renaming the file before uploading — e.g. mv gutenberg.zip gutenberg-plugin.zip — but that gives artifact name gutenberg-plugin.zip, not gutenberg-plugin.

So the choices are:

  1. Keep current approach (archive: false) — fixes double-zip, artifact name becomes gutenberg.zip
  2. Rename file first — fixes double-zip, artifact name becomes gutenberg-plugin.zip (still a change)
  3. Revert to original — keep name: gutenberg-plugin and accept the double-zip

Happy to implement whichever you prefer. If backward compatibility of the gutenberg-plugin artifact name is important, option 3 is the only way to preserve it exactly.

@luisherranz
Copy link
Copy Markdown
Member

@copilot, please update the PR description to follow this repository's template, including the What, Why, and How sections. Also, add these two screenshots and testing instructions stating that to test this PR, one must download the artifact and attempt to install it.

Before:

Screenshot 2026-03-27 at 12 53 42

After:

Screenshot 2026-03-27 at 12 54 15

Copy link
Copy Markdown
Contributor Author

Copilot AI commented Mar 27, 2026

@copilot, please update the PR description to follow this repository's template, including the What, Why, and How sections. Also, add these two screenshots and testing instructions stating that to tes...

Done — the PR description has been updated to follow the repository template with What, Why, How, Testing Instructions, and Screenshots sections, including the before/after screenshots in the standard table format.

@luisherranz
Copy link
Copy Markdown
Member

@youknowriad, @adamziel, what do you think? Is this worth it, or could it break unexpected integrations?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

[Type] Code Quality Issues or PRs that relate to code quality

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants