Add support for beta prereleases in workflows #60193

jorgeatorres · 2025-08-04T14:00:02Z

Changes proposed in this Pull Request:

The new versioning scheme, bringing back beta 1 and beta 2 and using RCs for internal deployment only means we need to make some adjustments to our workflows.

This PR introduces those changes. In particular:

Any version with -dev, -beta or -rc is now considered "prerelease" by the build workflow.
The "bump version" workflow now supports bumping -beta.N versions and also between -beta and -rc. Checks to prevent invalid workflows were enhanced as well.
The "Commits and Contributors" workflow is now triggered by a beta pre-release, and not RCs. Similarly, for Slack pings to DeAd about new releases.
The global changelog is only updated for stable releases, ignoring any -dev, -beta or -rc release.

Related to #60029.

How to test the changes in this Pull Request:

Using the WooCommerce Testing Instructions Guide, include your detailed testing instructions:

Fork the WooCommerce repository and set the release-related secrets as indicated in Build .0-dev release at code freeze time #60001. Ensure that release/10.1 is also included.
Use the GH UI or the tool of your choice and replace woocommerce/woocommerce for <yourusername>/woocommerce in both of these files:

woocommerce/.github/workflows/release-release-events-proxy.yml

Line 11 in c183a34

uses: woocommerce/woocommerce/.github/workflows/release-new-release-published.yml@trunk

woocommerce/.github/workflows/release-new-release-published.yml

Line 15 in e4e047f

uses: woocommerce/woocommerce/.github/workflows/release-commits-and-contributors.yml@trunk
Go to Actions > Release: Enforce Code Freeze and run the workflow. Confirm that after it finishes:
- A PR has been created bumping versions in trunk to 10.3.0-dev.
- Branch release/10.2 and milestone 10.3.0 have been created.
- A 10.2.0-dev pre-release has been created and published.
- The only Slack notification sent is about the code freeze itself.
Go to Actions > Release: Bump version number and test the version bump logic (always using release/10.2 as Release branch):
1. Confirm that the workflow fails for bump types dev, stable and rc.
2. Run the workflow with bump type beta and confirm that it creates a PR bumping versions to 10.2.0-beta.1. Merge this PR.
3. Confirm that the workflow fails for bump types dev and stable.
4. Run the workflow with bump type beta and confirm that it creates a PR bumping version sto 10.2.0-beta.2. Merge this PR.
5. Run the workflow again with bump type rc and confirm that it creates a PR bumping versions to 10.2.0-rc.1. Merge this PR.
6. Confirm that the workflow fails for bump types dev or beta.
7. Run the workflow again with bump type stable and confirm that it creates a PR bumping versions to 10.2.0. Merge this PR.
Go to Actions > _Release: Build ZIP file:
1. Run the workflow with release/10.1 as Release branch and make sure Create a draft GitHub release is checked. I suggest to Skip verification steps for testing purposes. Once the workflow completes, you should have a 10.1.0-rc.2 draft release in Code > Releases. Confirm that this is marked as pre-release by default.
2. Run the workflow with release/10.2 as Release branch and Create a draft GitHub release is checked. Same as above, I suggest to Skip verification steps. Once the workflow completes, you should have a 10.2.0 draft release in Code > Releases. Confirm that this is not marked as pre-release by default.
Go to Code > Releases and create draft releases with the following names: 10.3.0-dev, 10.3.0-beta.1, 10.3.0-rc.1 and 10.3.0. There's no need to upload a ZIP. Confirm that:
1. Publishing 10.3.0-dev and 10.3.0-rc.1 don't trigger any Slack notification.
2. Publishing 10.3.0-beta.1 triggers a Slack notification and runs the Call release commits and contributors workflow job as part of its associated Release: Release events proxy workfllow run.
3. PUblishing 10.3.0 triggers a Slack notifications as well, and in its Release: Release events proxy workfllow run it should not run the Call release commits and contributors workflow but should run the Update changelog.txt job.

Testing that has already taken place:

github-actions · 2025-08-04T20:05:33Z

Testing Guidelines

Hi @kalessil ,

Apart from reviewing the code changes, please make sure to review the testing instructions (Guide) and verify that relevant tests (E2E, Unit, Integration, etc.) have been added or updated as needed.

Reminder: PR reviewers are required to document testing performed. This includes:

🖼️ Screenshots or screen recordings.
📝 List of functionality tested / steps followed.
🌐 Site details (environment attributes such as hosting type, plugins, theme, store size, store age, and relevant settings).
🔍 Any analysis performed, such as assessing potential impacts on environment attributes and other plugins, conducting performance profiling, or using LLM/AI-based analysis.

⚠️ Within the testing details you provide, please ensure that no sensitive information (such as API keys, passwords, user data, etc.) is included in this public issue.

coderabbitai · 2025-08-04T20:12:10Z

📝 Walkthrough

Walkthrough

The workflows for release management were updated to include "beta" as a recognized prerelease type alongside "dev" and "rc." This affects version parsing, prerelease detection, job triggering, and changelog handling across several GitHub Actions workflow files. Regex patterns, conditional logic, and documentation were adjusted accordingly.

Changes

Cohort / File(s)	Change Summary
Release Build Prerelease Detection `.github/workflows/release-build-zip-file.yml`	Expanded prerelease detection to include "-dev" and "-beta" in addition to "-rc" for setting the `IS_PRERELEASE` environment variable, affecting how releases are marked as prereleases in the GitHub CLI release creation step.
Release Version Bump Logic `.github/workflows/release-bump-version.yml`	Added support for "beta" as a prerelease bump type. Updated version parsing, validation, bump logic, and changelog-clearing behavior to handle "beta" alongside "dev" and "rc." Simplified branch validation for bump types.
Release Version Parsing in Commits/Contributors `.github/workflows/release-commits-and-contributors.yml`	Changed version format recognition from "-rc.N" to "-beta.N" in input validation and regex, updating documentation and error messages to match. No other logic changes.
Release Event Job Triggering `.github/workflows/release-new-release-published.yml`	Refined job trigger conditions to target actions based on release type and tag naming. Jobs now differentiate between "beta," "dev," and "rc" tags for precise execution, especially for changelog and notification jobs.

Sequence Diagram(s)

sequenceDiagram
    participant Dev as Developer
    participant GH as GitHub Actions
    participant CLI as GitHub CLI

    Dev->>GH: Push tag or trigger release workflow
    GH->>GH: Parse version (recognize dev, beta, rc)
    GH->>GH: Determine bump type and validate transition
    GH->>GH: Set IS_PRERELEASE if version contains dev, beta, or rc
    GH->>CLI: Create GitHub release (with or without --prerelease)
    GH->>GH: Trigger jobs based on release tag (dev, beta, rc, stable)
    GH->>GH: Conditionally clear changelog and update files

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Possibly related PRs

Allow GH releases to be created from workflow #58657: Initially introduced prerelease detection for "-rc" tags in the release creation workflow, which this PR extends to "-beta" and "-dev".
Add workflow to bump WC core version #59563: Added "beta" prerelease support to the release-bump-version workflow, directly related to the expanded bump logic in this PR.
Move release related jobs to release-new-release-published.yml #59722: Restructured release workflows and refined job triggers in release-new-release-published.yml, which this PR further refines for "beta" and other prerelease types.

Note

⚡️ Unit Test Generation is now available in beta!

Learn more here, or try it out under "Finishing Touches" below.

✨ Finishing Touches

🧪 Generate unit tests

Create PR with unit tests
Post copyable unit tests in a comment
Commit unit tests in branch enhancement/60029/bump-version

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

Review comments: Directly reply to a review comment made by CodeRabbit. Example:
- I pushed a fix in commit <commit_id>, please review it.
- Explain this complex logic.
- Open a follow-up GitHub issue for this discussion.
Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
- @coderabbitai explain this code block.
PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
- @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
- @coderabbitai read src/utils.ts and explain its main purpose.
- @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR comments)

@coderabbitai pause to pause the reviews on a PR.
@coderabbitai resume to resume the paused reviews.
@coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
@coderabbitai full review to do a full review from scratch and review all the files again.
@coderabbitai summary to regenerate the summary of the PR.
@coderabbitai generate docstrings to generate docstrings for this PR.
@coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
@coderabbitai generate unit tests to generate unit tests for this PR.
@coderabbitai resolve resolve all the CodeRabbit review comments.
@coderabbitai configuration to show the current CodeRabbit configuration for the repository.
@coderabbitai help to get help.

Other keywords and placeholders

Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

Visit our Documentation for detailed information on how to use CodeRabbit.
Join our Discord Community to get help, request features, and share feedback.
Follow us on X/Twitter for updates and announcements.

coderabbitai

Actionable comments posted: 0

🧹 Nitpick comments (5)

.github/workflows/release-build-zip-file.yml (1)

252-257: Consolidate prerelease detection to avoid triple contains() repetition
Using three contains() calls is verbose and easy to forget when a new prerelease type is added. Consider computing is_prerelease once in a small github-script step (or a reusable action) and reuse its output here. This keeps the expression short and future-proof.

.github/workflows/release-commits-and-contributors.yml (1)

8-15: Input description & parser drift
The description still lists X.Y but the regex now always allows an optional .Z. Either drop the reference to X.Y or accept only the documented forms to avoid surprising users.

.github/workflows/release-bump-version.yml (3)

64-74: Duplicate semver regex across workflows
The same (or very similar) regex now lives in at least three files. Extracting it to a tiny JS module or a reusable composite action would remove copy-paste bugs when the version scheme changes again.

76-82: invalidBump condition is getting hard to reason about
The chained boolean expression is already five clauses long. A small state-transition map (current->allowed bumps) would be more readable and less error-prone.

133-135: Perl one-liner risks wiping legitimate changelog content
Multi-line, greedy .* can over-match if the readme header format ever changes. Consider a purpose-built script (or at least anchoring the look-behind to = Unreleased = section) to safeguard historical entries.

📜 Review details

Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b0d3b64 and e4e047f.

📒 Files selected for processing (4)

.github/workflows/release-build-zip-file.yml (1 hunks)
.github/workflows/release-bump-version.yml (5 hunks)
.github/workflows/release-commits-and-contributors.yml (2 hunks)
.github/workflows/release-new-release-published.yml (3 hunks)

🧰 Additional context used

🧠 Learnings (6)

📓 Common learnings

Learnt from: CR
PR: woocommerce/woocommerce#0
File: .cursor/rules/generate-pr-description.mdc:0-0
Timestamp: 2025-07-21T05:22:46.426Z
Learning: Provide clear, step-by-step instructions for how to test the changes in the PR description.

Learnt from: jorgeatorres
PR: woocommerce/woocommerce#59675
File: .github/workflows/release-bump-as-requirement.yml:48-65
Timestamp: 2025-07-15T15:39:21.856Z
Learning: In WooCommerce core repository, changelog entries for all PRs live in `plugins/woocommerce/changelog/` directory and are processed during releases, not at the repository root level.

Learnt from: prettyboymp
PR: woocommerce/woocommerce#59048
File: .github/workflows/cherry-pick-milestoned-prs.yml:118-131
Timestamp: 2025-07-11T13:05:08.440Z
Learning: In GitHub Actions workflows, when reviewing steps that access event data like `github.event.pull_request.milestone`, check the entire job dependency chain and conditional logic. If upstream jobs already validate the data exists (like checking `github.event.pull_request.milestone != null` in a prerequisite job), then downstream jobs don't need redundant null-checks since the data is guaranteed to exist by that point.

📚 Learning: in github actions workflows, when reviewing steps that access event data like `github.event.pull_req...

Learnt from: prettyboymp
PR: woocommerce/woocommerce#59048
File: .github/workflows/cherry-pick-milestoned-prs.yml:118-131
Timestamp: 2025-07-11T13:05:08.440Z
Learning: In GitHub Actions workflows, when reviewing steps that access event data like `github.event.pull_request.milestone`, check the entire job dependency chain and conditional logic. If upstream jobs already validate the data exists (like checking `github.event.pull_request.milestone != null` in a prerequisite job), then downstream jobs don't need redundant null-checks since the data is guaranteed to exist by that point.

Applied to files:

.github/workflows/release-build-zip-file.yml
.github/workflows/release-new-release-published.yml

📚 Learning: in woocommerce core repository, changelog entries for all prs live in `plugins/woocommerce/changelog...

Learnt from: jorgeatorres
PR: woocommerce/woocommerce#59675
File: .github/workflows/release-bump-as-requirement.yml:48-65
Timestamp: 2025-07-15T15:39:21.856Z
Learning: In WooCommerce core repository, changelog entries for all PRs live in `plugins/woocommerce/changelog/` directory and are processed during releases, not at the repository root level.

Applied to files:

.github/workflows/release-new-release-published.yml
.github/workflows/release-bump-version.yml

📚 Learning: woocommerce trunk versions follow the pattern `x.y.0-dev` where the patch version is always `0`. thi...

Learnt from: jorgeatorres
PR: woocommerce/woocommerce#59946
File: .github/workflows/release-code-freeze.yml:108-124
Timestamp: 2025-07-23T19:42:10.564Z
Learning: WooCommerce trunk versions follow the pattern `X.Y.0-dev` where the patch version is always `0`. This means when calculating release branches, string operations like `slice(0, -2)` on the version after removing `-dev` will always work correctly since the input format is predictable (e.g., `10.2.0` → `10.2`).

Applied to files:

.github/workflows/release-bump-version.yml

📚 Learning: to watch for changes, use 'pnpm --filter=@woocommerce/plugin-woocommerce watch:build' to ensure expe...

Learnt from: CR
PR: woocommerce/woocommerce#0
File: .cursor/rules/woo-build.mdc:0-0
Timestamp: 2025-07-28T05:05:41.091Z
Learning: To watch for changes, use 'pnpm --filter=@woocommerce/plugin-woocommerce watch:build' to ensure experimental features are active during development builds.

Applied to files:

.github/workflows/release-bump-version.yml

📚 Learning: woocommerce uses wordpress versioning conventions where minor versions in x.y.z format are constrain...

Learnt from: prettyboymp
PR: woocommerce/woocommerce#59048
File: .github/workflows/cherry-pick-milestoned-prs.yml:60-83
Timestamp: 2025-06-26T12:45:40.709Z
Learning: WooCommerce uses WordPress versioning conventions where minor versions in X.Y.Z format are constrained to 0-9 (Y cannot exceed 9). This means version increment logic should reset minor to 0 and increment major when minor reaches 9, rather than allowing two-digit minor versions like 9.10 or 9.11.

Applied to files:

.github/workflows/release-bump-version.yml

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

GitHub Check: Remind reviewers to also review the testing instructions and test coverage

🔇 Additional comments (2)

.github/workflows/release-commits-and-contributors.yml (1)

39-42: No “-rc” references found in workflows
Ran a repository-wide search in .github/workflows for -rc. and confirmed there are no hard-coded references remaining.

.github/workflows/release-new-release-published.yml (1)

14-15: Conditions read clearly and match the new policy – looks good

kalessil · 2025-08-05T06:50:17Z

.github/workflows/release-new-release-published.yml

@@ -36,7 +36,7 @@ jobs:
  update-global-changelog:
    name: 'Update changelog.txt after any stable release'
    runs-on: ${{ ( github.repository == 'woocommerce/woocommerce' && 'blacksmith-2vcpu-ubuntu-2404' ) || 'ubuntu-latest' }}
-    if: ${{ github.event.action == 'published' && ! contains( inputs.release_tag_name, '-rc' ) }}
+    if: ${{ github.event.action == 'published' && ! ( contains( inputs.release_tag_name, '-dev' ) || contains( inputs.release_tag_name, '-beta' ) || contains( inputs.release_tag_name, '-rc' ) ) }}


Any potential issues with relying on github.event.release.prerelease instead?

.github/workflows/release-new-release-published.yml

.github/workflows/release-bump-version.yml

kalessil · 2025-08-05T09:31:55Z

Testing in progress:

Go to Actions > Release: Enforce Code Freeze and run the workflow. Confirm that after it finishes
Go to Actions > Release: Bump version number and test the version bump logic (always using release/10.2 as Release branch)
Go to Actions > _Release: Build ZIP file: ...
Go to Code > Releases and create draft releases with the following names: 10.3.0-dev, 10.3.0-beta.1, 10.3.0-rc.1 and 10.3.0. There's no need to upload a ZIP. Confirm that ...

jorgeatorres · 2025-08-05T09:51:45Z

Note: milestone version created differs: 10.3.0 instead of 10.2.0

This is indeed correct. I had the wrong version in the testing instructions. Apologies @kalessil!

kalessil

LGTM and manual tests are passing as described!

github-actions bot added the focus: monorepo infrastructure Issues and PRs related to monorepo tooling. label Aug 4, 2025

jorgeatorres changed the title ~~Add support for beta prereleases in workflows~~ Add support for beta prereleases in version bump workflow Aug 4, 2025

jorgeatorres added 2 commits August 4, 2025 18:06

Add support for ‘beta’ prereleases

ff03ab4

Clear changelog in readme when bumping version to a new stable

a4894fc

jorgeatorres force-pushed the enhancement/60029/bump-version branch 2 times, most recently from 9ea9b98 to c6d3f78 Compare August 4, 2025 18:28

Update other workflows to handle prereleases

e4e047f

jorgeatorres force-pushed the enhancement/60029/bump-version branch from c6d3f78 to e4e047f Compare August 4, 2025 18:30

jorgeatorres changed the title ~~Add support for beta prereleases in version bump workflow~~ Add support for beta prereleases in workflows Aug 4, 2025

jorgeatorres marked this pull request as ready for review August 4, 2025 20:05

jorgeatorres requested a review from a team as a code owner August 4, 2025 20:05

jorgeatorres requested review from kalessil and removed request for a team August 4, 2025 20:05

woocommercebot requested a review from a team August 4, 2025 20:05

coderabbitai bot reviewed Aug 4, 2025

View reviewed changes

kalessil reviewed Aug 5, 2025

View reviewed changes

jorgeatorres requested a review from kalessil August 5, 2025 09:28

kalessil approved these changes Aug 5, 2025

View reviewed changes

jorgeatorres merged commit a3b1a5b into trunk Aug 5, 2025
29 of 31 checks passed

jorgeatorres deleted the enhancement/60029/bump-version branch August 5, 2025 14:08

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Add support for beta prereleases in workflows #60193

Add support for beta prereleases in workflows #60193

Uh oh!

jorgeatorres commented Aug 4, 2025 •

edited

Loading

Uh oh!

github-actions bot commented Aug 4, 2025 •

edited

Loading

Uh oh!

coderabbitai bot commented Aug 4, 2025

Walkthrough

Changes

Sequence Diagram(s)

Estimated code review effort

Possibly related PRs

Chat

Support

CodeRabbit Commands (Invoked using PR comments)

Other keywords and placeholders

Documentation and Community

Uh oh!

coderabbitai bot left a comment

Uh oh!

kalessil Aug 5, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kalessil commented Aug 5, 2025 •

edited

Loading

Uh oh!

jorgeatorres commented Aug 5, 2025

Uh oh!

kalessil left a comment

Uh oh!

Uh oh!

Uh oh!

Add support for beta prereleases in workflows #60193

Add support for beta prereleases in workflows #60193

Uh oh!

Conversation

jorgeatorres commented Aug 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes proposed in this Pull Request:

How to test the changes in this Pull Request:

Testing that has already taken place:

Uh oh!

github-actions bot commented Aug 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Testing Guidelines

Uh oh!

coderabbitai bot commented Aug 4, 2025

Walkthrough

Changes

Sequence Diagram(s)

Estimated code review effort

Possibly related PRs

Chat

Support

CodeRabbit Commands (Invoked using PR comments)

Other keywords and placeholders

Documentation and Community

Uh oh!

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

kalessil Aug 5, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kalessil commented Aug 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jorgeatorres commented Aug 5, 2025

Uh oh!

kalessil left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jorgeatorres commented Aug 4, 2025 •

edited

Loading

github-actions bot commented Aug 4, 2025 •

edited

Loading

kalessil commented Aug 5, 2025 •

edited

Loading