Size Change: 0 B

Total Size: 7.97 MB

_{compressed-size-action}

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.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @demo@local, @Copilot.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

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

Unlinked contributors: demo@local, Copilot.

Co-authored-by: paulopmt1 <paulopmt1@git.wordpress.org>
Co-authored-by: mikachan <mikachan@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>

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

Since both creating the git tags and publishing the npm packages can independently fail, a natural question I have for the direction proposed here is: What happens if the npm publish succeeds and then the git tagging fails? That leaves us with a published npm version and without the git tag, right?

Maybe this is still an improvement if it's more likely for one to fail than the other that it makes sense to flip the behavior.

But to me it feels like if either one fails, we should roll back to undo the other. And since (if my reading is correct) we cannot unpublish new versions of the npm package but we can delete git tags, it seems like we'd want a procedure like:

gitTag();
try {
  npmPublish();
} catch {
  deleteGitTag();
}

Since both creating the git tags and publishing the npm packages can independently fail, a natural question I have for the direction proposed here is: What happens if the npm publish succeeds and then the git tagging fails? That leaves us with a published npm version and without the git tag, right?

Maybe this is still an improvement if it's more likely for one to fail than the other that it makes sense to flip the behavior.

But to me it feels like if either one fails, we should roll back to undo the other. And since (if my reading is correct) we cannot unpublish new versions of the npm package but we can delete git tags, it seems like we'd want a procedure like:

gitTag();
try {
  npmPublish();
} catch {
  deleteGitTag();
}

You're right @aduth, the asymmetric window exists, but I think the current seems more reliable than tag -> try publish -> catch deleteTag because:

• It has a smaller window: seconds (one push) vs minutes (full Lerna publish over ~100 packages).
• Rollback isn't free: deleteTag has the same failure modes as the push, so it can itself fail and leave us in the stuck state.
• Better recovery: "publish without tags" auto-recovers on workflow re-run (lerna skips already-published versions because we use from-package filter).

Since both creating the git tags and publishing the npm packages can independently fail

To reduce the chance of that happening for git tags, I added a retry attempt, so it should increase the success rate of that command.

I'm curious to hear your thoughts on this new proposal.

Yeah, on second thought, it seems like it's much less likely for the git tagging to fail and much easier to recover from. The built-in retry as proposed could further help reduce the likelihood of this failing. This direction seems like it would be an improvement 👍

@copilot resolve the merge conflicts in this pull request

@copilot resolve the merge conflicts in this pull request

Resolved in 3db81ff. The trunk had migrated bin/plugin/commands/packages.js → tools/release/commands/packages.js (via #77695). The merge brought that rename in, and all PR changes (the --no-push flag, the retry push loop, and the err.message in the log) are now correctly applied to the new file path. I also fixed a spaces-vs-tabs indentation issue in the retry log that was introduced in the previous commit.

Flaky tests detected in 63d3db4.
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/26057776719
📝 Reported issues:

• [Flaky Test] Navigates the items list via UP/DOWN arrow keys #64334 in /test/e2e/specs/site-editor/dataviews-list-layout-keyboard.spec.js
• [Flaky Test] can be converted when nested to paragraphs #48507 in /test/e2e/specs/editor/blocks/list.spec.js

I was fixing a similar mess few months ago in #74413. Back then the failure was:

1. lerna sucessfully bumped the versions and pushed changes to the wp/next branch, probably together will all the new tags.
2. then the NPM publishing also succeeded
3. finally, the changes in wp/next (package.json version bumps, changelog updates) are merged back to trunk. And that failed because of merge conflicts between wp/next and trunk, they needed to be resolved manually.

At that time I didn't yet know that the changes made in step 1 are pushed to wp/next, I thought they were lost.

The issue being fixed here is a bit different, here the step 2 failed. One downside of this PR (push to wp/next only after publish) is that when the push fails after successful NPM publish, the changes that you just published to a public registry have no record in Git, the record is lost. On the other hand, the NPM publish can be always done again from the wp/next branch, there is no information loss. It's not easy, you have to do it manually from a local checkout, get the NPM credentials from somewhere. But possible, I think I've done it once.

On the other hand, it's always a tradeoff, as has been discussed. There's no perfect solution to this distributed network operation 🙂