Move release related jobs to release-new-release-published.yml
#59722
Conversation
559d775 to
c38bbeb
Compare
Testing GuidelinesHi @jorgeatorres @woocommerce/flux, 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:
|
📝 WalkthroughWalkthroughThe release workflow was refactored to be reusable via Changes
Sequence Diagram(s)sequenceDiagram
participant GitHub Release Event
participant Proxy Workflow (release-release-events-proxy.yml)
participant Reusable Workflow (release-new-release-published.yml)
participant Release Commits & Contributors Workflow
GitHub Release Event->>Proxy Workflow: Trigger on prereleased/published
Proxy Workflow->>Reusable Workflow: Call with release_tag_name input
alt If action is prereleased
Reusable Workflow->>Release Commits & Contributors Workflow: Call with version input
else If action is published
Reusable Workflow->>Slack/Changelog Jobs: Run with release_tag_name input
end
Possibly related PRs
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 2
🔭 Outside diff range comments (1)
.github/workflows/release-new-release-published.yml (1)
24-34: Slack notification fires for all published releases, including RCs and beta-tester tags
notify-release-publishedtriggers onpublishedonly and no longer filters out tags such as-rcorwc-beta-tester.
This will spam the public Slack channel for every release candidate.Re-introduce the filter you removed or adapt the condition:
-if: ${{ github.event.action == 'published' }} +if: ${{ github.event.action == 'published' && !contains(inputs.release_tag_name, '-rc') && !contains(inputs.release_tag_name, 'wc-beta-tester') }}
🧹 Nitpick comments (2)
.github/workflows/release-release-events-proxy.yml (1)
8-14: Job identifier/name no longer reflects the broader scopeNow that the job covers all release-event types, the id
call-new-release-published-workflowand display name are misleading.
Consider renaming to something neutral such ascall-release-events-workflowto avoid confusion for future maintainers..github/workflows/release-new-release-published.yml (1)
50-53: Fail-fast path missing an earlyset -eThe script block downloads and unzips assets, then manually exits on failure, but earlier commands (
gh release download,unzip) could fail silently.
Addset -euo pipefailto catch such errors immediately.run: | - gh release download "$RELEASE_TAG" --pattern 'woocommerce.zip' + set -euo pipefail + gh release download "$RELEASE_TAG" --pattern 'woocommerce.zip' unzip -qq woocommerce.zip
📜 Review details
Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/release-new-release-published.yml(3 hunks).github/workflows/release-release-events-proxy.yml(1 hunks)
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: jorgeatorres
PR: woocommerce/woocommerce#59675
File: .github/workflows/release-bump-as-requirement.yml:48-65
Timestamp: 2025-07-15T15:39:21.815Z
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.430Z
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.
Learnt from: CR
PR: woocommerce/woocommerce#0
File: .cursor/rules/generate-pr-description.mdc:0-0
Timestamp: 2025-06-30T09:26:55.361Z
Learning: Provide clear, step-by-step instructions for how to test the changes in the PR description.
.github/workflows/release-release-events-proxy.yml (1)
Learnt from: prettyboymp
PR: woocommerce/woocommerce#59048
File: .github/workflows/cherry-pick-milestoned-prs.yml:118-131
Timestamp: 2025-07-11T13:05:08.430Z
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.
.github/workflows/release-new-release-published.yml (4)
Learnt from: jorgeatorres
PR: woocommerce/woocommerce#59675
File: .github/workflows/release-bump-as-requirement.yml:48-65
Timestamp: 2025-07-15T15:39:21.815Z
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.430Z
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.
Learnt from: CR
PR: woocommerce/woocommerce#0
File: .cursor/rules/generate-pr-description.mdc:0-0
Timestamp: 2025-06-30T09:26:55.361Z
Learning: Applies to .github/PULL_REQUEST_TEMPLATE.md : The changelog section in the PR description must keep the markdown structure from the PR template exactly as-is, including all checkboxes, comments, and headings. Only the appropriate checkbox may be checked, and the changelog message must be placed under the `#### Comment` heading and before the closing `</details>` tag. Do not add, remove, or reformat any part of the changelog section except for checking the box and adding the message in the correct place.
Learnt from: CR
PR: woocommerce/woocommerce#0
File: .cursor/rules/generate-pr-description.mdc:0-0
Timestamp: 2025-06-30T09:26:55.361Z
Learning: Applies to .github/PULL_REQUEST_TEMPLATE.md : Do not remove or alter required markdown sections in the PR description, especially those used by automation (e.g., changelog entry details and comments).
🔇 Additional comments (1)
.github/workflows/release-new-release-published.yml (1)
12-18: Guard expression relies ongithub.event.action, which is undefined outside a release eventWhen this workflow is invoked via
workflow_call, the event context is forwarded today, but that is an implementation detail.
If a future caller (or a manual dispatch) omits a release event payload,github.event.actionwill be empty, the expression will evaluate tofalsebut still be syntactically valid and might hide problems.A safer, explicit pattern is to pass the action as an input and base the condition on that, e.g.:
inputs: release_action: description: Release event action required: true type: stringand then
-if: ${{ github.event.action == 'prereleased' }} +if: ${{ inputs.release_action == 'prereleased' }}Same for the
publishedchecks below.
There was a problem hiding this comment.
LGTM. Thanks @albarin!
For proper testing I had to cherry pick the proxy workflow to the release/10.0 branch in my fork, but that's a one off thing and expected.
Confirmed (in my fork) that:
- Publishing a pre-release triggers the proxy workflow and notifies in Slack + generates contributors list.
- Publishing a final release triggers the proxy workflow and notifies in Slack, updates the global changelog but doesn't generate the contributors list (as expected).
- Publishing a pre or final release with
wc-beta-testeras prefix skips the workflow entirely. - Publishing a pre or final release with wrong version tag doesn't entirely fail the workflow but that's #59742, so not a blocker.
Submission Review Guidelines:
Changes proposed in this Pull Request:
Problem
Previously, workflows triggered by release events (like published or prereleased) would run using the workflow code from the tagged commit. This meant that if a release branch was created weeks ago, any improvements made to the workflow files since then would not be applied during the release process.
Solution
This can be fixed by having a "proxy" workflow that runs on the
prereleasedandpublishedevents and calls a dispatchable workflow pinned at trunk. This PR implements this with two workflows:release-release-events-proxy.yml) - Triggers on both release events and dispatches to the main workflow intrunk.release-new-release-published.yml) - Contains the actual logic and always runs fromtrunk. This workflow contains the logic to distinguish betweenpublishedandprereleasedevents and calls the corresponding flows depending on the trigger.Part of #59533
How to test the changes in this Pull Request:
Using the WooCommerce Testing Instructions Guide, include your detailed testing instructions:
Preparation
woocommerce/woocommercerepo with all branches into your GH account.Settings > Secrets and variables > Actionsand create 3 new repository secrets:CODE_FREEZE_BOT_TOKEN, get the token value from theTest Assistant botfrom the secret store.WOO_RELEASE_SLACK_CHANNEL: You can use the test channeltest-woo-core-release-notifications.WOO_RELEASE_SLACK_NOTIFICATION_CHANNEL: You can use the test channeltest-woo-core-release-notifications.59533/proxy-new-releaseand merge it (to get this new workflow intotrunk).woocommerce/woocommercewith your fork name:YOUR_REPO/woocommercein:Test 1: Publishing a pre-release
Releases, click onDraft a new release, create a new release with a correct version pre-release format tag (like9.9-rc.1and branchrelease/9.9), and save it aspre-release.Release: Release events proxy workflowand calls therelease-commits-and-contributors.yml👇 andNotify in Slack when a new release is publishedandUpdate changelog.txt after any stable releaseare skipped.Test 2: Publishing a release
Releases, click onDraft a new release, create a new release with a correct version format tag (like9.9and branchrelease/9.9), and save it as a final release.Release: Release events proxy workflowandNotify in Slack when a new release is published, andUpdate changelog.txt after any stable releaseare triggered.release-commits-and-contributors.ymlshould be skipped.Testing that has already taken place:
Changelog entry
Changelog Entry Details
Significance
Type
Message
Changelog Entry Comment
Comment