CI: Don't build release notes during plugin build workflow for WP Core sync

[ockham]

What?

Fixes a bug in the "Build Gutenberg Plugin Zip" GHA workflow.

Why?

When manually running the "Build Gutenberg Plugin Zip" GHA workflow to publish version 22.7.0 RC 3 of the plugin, it failed with the following error:

Error: Failed to CreateArtifact: Received non-retryable error: Failed request: (409) Conflict: an artifact with this name already exists on the workflow run

Reported here: #75844 (comment).

How?

tl;dr By only generating and uploading the release notes artifact if run for the IS_GUTENBERG_PLUGIN case (and skipping otherwise).

For a more detailed explanation, refer to #75844 (comment).

Testing Instructions

Gotta manually run the "Build Gutenberg Plugin Zip" GHA workflow to find out 😬
(Should cherry-pick this PR to the release/22.7 before attempting.)

Follow-up

There's some more opportunity for cleanup/optimization of that workflow (but not critical to unblock the GB 22.7.0 release). I'll file another PR in the near future.

[scruffian]

The reasoning makes sense to me.

[github-actions]

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ockham <bernhard-reiter@git.wordpress.org>
Co-authored-by: scruffian <scruffian@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[scruffian]

I just cherry-picked this PR to the release/22.7 branch to get it included in the next release: 20688f7

[github-actions]

Flaky tests detected in 2f1ede7.
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/22958434831
📝 Reported issues:

• [Flaky Test] Custom Completer: should insert option #47280 in /test/e2e/specs/editor/various/autocomplete-and-mentions.spec.js
• [Flaky Test] User Mention: should allow mention selection via keypress event #48416 in /test/e2e/specs/editor/various/autocomplete-and-mentions.spec.js
• [Flaky Test] inserts a block in proper place after having clicked Browse All from block appender #45331 in /test/e2e/specs/editor/various/inserting-blocks.spec.js

[ockham]

Looks like it worked 🎉 https://github.com/WordPress/gutenberg/actions/runs/22959467975

[desrosj]

Thanks for spotting this and fixing @ockham/@scruffian! This change makes sense.

Process question: do Gutenberg releases ever happen within the wp/X.Y branches? Perhaps for security releases? If so, this should likely get the Backport to WP 7.0 Branch label as well.

I considered whether it would be better to separate these 2 steps into a separate job entirely. These steps are not directly related to "building the plugin asset," and it's not very clear when these steps actually run without knowing they happen as a part of the build job and looking in the log.

But unfortunately, npm run other:changelog requires a full npm install. So these two steps would go from ~2 seconds to ~2 minutes, and I don't think that tradeoff is worth it at this time.

I posed the question of "how to make it so the other:changelog script could run without requiring a full npm i" to Claude, and this was what it came up with:

- name: Install changelog script dependencies
  run: |
      # Install only the packages required by bin/plugin/commands/changelog.js
      # and its dependencies, rather than the full project install.
      npm install --no-save \
        "@octokit/rest@$(jq -r '.packages["node_modules/@octokit/rest"].version' package-lock.json)" \
        "sprintf-js@$(jq -r '.packages["node_modules/sprintf-js"].version' package-lock.json)" \
        "semver@$(jq -r '.packages["node_modules/semver"].version' package-lock.json)" \
        "commander@$(jq -r '.packages["node_modules/commander"].version' package-lock.json)" \
        "chalk@$(jq -r '.packages["node_modules/chalk"].version' package-lock.json)"

If there were an easy way to have a "separate" package.json or text file containing the required dependencies for the script, then I think that would potentially be worth pursuing (maybe creating a package for the script instead of including it in the bin?), but having to list each one out in this step is just asking for a change to be missed in the future.

[ockham]

Process question: do Gutenberg releases ever happen within the wp/X.Y branches? Perhaps for security releases? If so, this should likely get the Backport to WP 7.0 Branch label as well.

I don't think we ever run GB releases from wp/X.Y branches. The latter are only used to sync GB code over to Core, and to release npms.

I considered whether it would be better to separate these 2 steps into a separate job entirely. These steps are not directly related to "building the plugin asset," and it's not very clear when these steps actually run without knowing they happen as a part of the build job and looking in the log.

But unfortunately, npm run other:changelog requires a full npm install. So these two steps would go from ~2 seconds to ~2 minutes, and I don't think that tradeoff is worth it at this time.

It's a bit of a chicken-egg problem I think. We're trying to isolate the build step as much as possible, and to share the resulting plugin zip available elsewhere (GB release, Core sync) -- previously only through GHA artifact upload and download, now also via GHCR. But as you've observed, right not release notes generation shares the npm install requirement, so it's kind of inextricable from the build step.

I posed the question of "how to make it so the other:changelog script could run without requiring a full npm i" to Claude, and this was what it came up with:

- name: Install changelog script dependencies
  run: |
      # Install only the packages required by bin/plugin/commands/changelog.js
      # and its dependencies, rather than the full project install.
      npm install --no-save \
        "@octokit/rest@$(jq -r '.packages["node_modules/@octokit/rest"].version' package-lock.json)" \
        "sprintf-js@$(jq -r '.packages["node_modules/sprintf-js"].version' package-lock.json)" \
        "semver@$(jq -r '.packages["node_modules/semver"].version' package-lock.json)" \
        "commander@$(jq -r '.packages["node_modules/commander"].version' package-lock.json)" \
        "chalk@$(jq -r '.packages["node_modules/chalk"].version' package-lock.json)"

If there were an easy way to have a "separate" package.json or text file containing the required dependencies for the script, then I think that would potentially be worth pursuing (maybe creating a package for the script instead of including it in the bin?), but having to list each one out in this step is just asking for a change to be missed in the future.

Agree 100% -- it'd be way too fragile to list those dependencies individually. I'm not sure I love the idea of yet another package for a tool that's never going to be "shipped" as part of GB, but maybe we can explore some options. Maybe the bin/ folder can get its own package.json? Or maybe we can rewrite the changelog generation script in a different language (PHP or shell) that doesn't require any dependencies? 🤔