Add slack notifications for open issues prior to release build. #60272
Conversation
Testing GuidelinesHi @kalessil @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:
|
📝 WalkthroughWalkthroughA new GitHub Actions workflow has been introduced to monitor upcoming WooCommerce release events. It runs daily and on manual trigger, checks for imminent releases via a public calendar, identifies open issues and PRs assigned to the corresponding milestone, and sends a Slack notification if any are found. Changes
Sequence Diagram(s)sequenceDiagram
participant Scheduler as GitHub Actions (Scheduled/Manual)
participant Calendar as Google Calendar (ICS)
participant GitHub as GitHub API
participant Slack as Slack API
Scheduler->>Calendar: Fetch ICS feed for release events
Calendar-->>Scheduler: Return upcoming events
Scheduler->>Scheduler: Parse and filter for next release event
alt Release event found
Scheduler->>GitHub: Query open issues/PRs for release milestone
GitHub-->>Scheduler: Return list of open items
alt Open items found
Scheduler->>Slack: Send formatted message with open items
Slack-->>Scheduler: Acknowledge delivery
else No open items
Scheduler->>Scheduler: Skip Slack notification
end
else No release event
Scheduler->>Scheduler: Exit workflow
end
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Note 🔌 MCP (Model Context Protocol) integration is now available in Early Access!Pro users can now connect to remote MCP servers under the Integrations page to get reviews and chat conversations that understand additional development context. ✨ Finishing Touches🧪 Generate unit tests
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. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (7)
.github/workflows/release-open-issue-warning.yml (7)
60-60: Fix log message wordingThis branch handles the absence of release events, not “Code Freeze”.
- console.log(`No Code Freeze events found in the specified range.`); + console.log(`No release build events found in the specified range.`);
115-117: Include team reviewers in “waiting on …”The API returns both users and teams; include teams so the message reflects all pending reviewers.
- if (reviewers.data.users && reviewers.data.users.length > 0) { - waitingOn.push(...reviewers.data.users.map(r => r.login)); - } + if (reviewers.data.users?.length) { + waitingOn.push(...reviewers.data.users.map(r => r.login)); + } + if (reviewers.data.teams?.length) { + waitingOn.push(...reviewers.data.teams.map(t => `@${t.slug}`)); + }
135-135: Minor Slack formatting tweakSquare brackets don’t add value in Slack; simplify the bullet for readability.
- const formattedItem = `• [#${item.number}] <${itemUrl}|${item.title}> (${author})\n Created ${createdDate} · ${waitingOnText}`; + const formattedItem = `• #${item.number} <${itemUrl}|${item.title}> (${author})\n Created ${createdDate} · ${waitingOnText}`;
145-148: If only 20 items are listed, indicate truncation in the headerYou’re showing up to 20 but using total_count in the header. Make it explicit when truncated to avoid confusion.
- const slackMessage = [ - `🚨 Milestone ${milestone} has ${searchResults.data.total_count} open items for ${releaseEventTitle} on ${formattedDate}\n`, + const shown = items.length; + const total = searchResults.data.total_count; + const header = `🚨 Milestone ${milestone} has ${total} open items for ${releaseEventTitle} on ${formattedDate}${shown < total ? ` (showing first ${shown})` : ''}\n`; + const slackMessage = [ + header, ...items ].join('\n');
159-169: Simplify Slack step input and optionally gate posting to upstream repoNo need to pass SLACK_MESSAGE via env. Also consider gating posts to the main repo to avoid accidental posts from forks (manual runs).
- - name: Send Slack Message - if: ${{ steps.get-milestone-items.outputs.has-items == 'true' }} + - name: Send Slack Message + if: ${{ steps.get-milestone-items.outputs.has-items == 'true' && github.repository == 'woocommerce/woocommerce' }} uses: archive/github-actions-slack@c643e5093620d65506466f2c9b317d5d29a5e517 # v2.10.1 - env: - SLACK_MESSAGE: ${{ steps.get-milestone-items.outputs.slack-message }} with: slack-bot-user-oauth-access-token: ${{ secrets.CODE_FREEZE_BOT_TOKEN }} slack-optional-unfurl_links: false slack-channel: ${{ secrets.WOO_RELEASE_SLACK_NOTIFICATION_CHANNEL }} - slack-text: | - ${{ env.SLACK_MESSAGE }} + slack-text: ${{ steps.get-milestone-items.outputs.slack-message }}If you prefer to allow forks to test Slack, drop the repository gate and keep the simplification.
12-15: Add concurrency control to prevent duplicate notificationsAvoid overlapping runs from schedule/manual triggers posting twice.
check-upcoming-release-events: name: Check for upcoming release events runs-on: ${{ ( github.repository == 'woocommerce/woocommerce' && 'blacksmith-2vcpu-ubuntu-2404' ) || 'ubuntu-latest' }} + concurrency: + group: release-open-issue-warning + cancel-in-progress: true
36-36: Trim trailing whitespace to satisfy yamllintYAMLlint flags trailing spaces on the listed lines. Please strip them.
If you use Prettier, enable trimming on save or run:
- pnpm prettier --write .github/workflows/release-open-issue-warning.yml
- or: yamllint -f colored .github/workflows/release-open-issue-warning.yml
Also applies to: 38-38, 41-41, 44-44, 74-74, 76-76, 80-80, 86-86, 88-88, 94-94, 96-96, 100-100, 105-105, 114-114, 122-122, 126-126, 127-127, 128-128, 130-130, 131-131, 136-136, 143-143, 149-149, 153-153
📜 Review details
Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/release-open-issue-warning.yml(1 hunks)
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: jorgeatorres
PR: woocommerce/woocommerce#60262
File: .github/workflows/release-build-zip-file.yml:133-138
Timestamp: 2025-08-08T08:14:35.037Z
Learning: WooCommerce milestone convention: The woocommerce/woocommerce repository only creates GitHub milestones in the x.y.0 format, and those milestones cover RCs and patch releases for that minor train. In .github/workflows/release-build-zip-file.yml, the pre-build verification that sets `milestone="$version_prefix.0"` is intentional and should remain as-is; using `$version_prefix` alone would be incorrect for this repo.
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.
Learnt from: senadir
PR: woocommerce/woocommerce#59325
File: plugins/woocommerce/includes/wc-formatting-functions.php:1211-1226
Timestamp: 2025-07-01T16:24:23.871Z
Learning: Action Scheduler is bundled into WooCommerce and always available, so there's no need to add fallback logic to WordPress cron functions when using Action Scheduler functions like as_schedule_single_action() and as_unschedule_all_actions() in WooCommerce code.
Learnt from: jorgeatorres
PR: woocommerce/woocommerce#60250
File: .github/workflows/release-compile-changelog.yml:165-166
Timestamp: 2025-08-07T10:34:27.702Z
Learning: In WooCommerce release workflows, the VERSION variable used in changelog generation comes from the `validate-selected-branch-version` step, which extracts the version from `plugins/woocommerce/woocommerce.php` using `grep -oP '(?<=Version: )(.+)'` and validates it matches the input version. This ensures the version is always in the correct format by the time it reaches the changelog generation step, making additional error handling for version format validation unnecessary.
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.
📚 Learning: 2025-08-08T08:14:35.037Z
Learnt from: jorgeatorres
PR: woocommerce/woocommerce#60262
File: .github/workflows/release-build-zip-file.yml:133-138
Timestamp: 2025-08-08T08:14:35.037Z
Learning: WooCommerce milestone convention: The woocommerce/woocommerce repository only creates GitHub milestones in the x.y.0 format, and those milestones cover RCs and patch releases for that minor train. In .github/workflows/release-build-zip-file.yml, the pre-build verification that sets `milestone="$version_prefix.0"` is intentional and should remain as-is; using `$version_prefix` alone would be incorrect for this repo.
Applied to files:
.github/workflows/release-open-issue-warning.yml
📚 Learning: 2025-07-11T13:05:08.440Z
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-open-issue-warning.yml
📚 Learning: 2025-08-08T08:15:10.569Z
Learnt from: jorgeatorres
PR: woocommerce/woocommerce#60262
File: .github/workflows/release-build-zip-file.yml:125-130
Timestamp: 2025-08-08T08:15:10.569Z
Learning: In .github/workflows/release-build-zip-file.yml, the env var BRANCH in the verify/build jobs is set from the required `branch` input (e.g., `release/x.y`) rather than a Git ref. Using `gh pr list --search "base:$BRANCH"` is valid because `branch` is always a plain branch name in this workflow.
Applied to files:
.github/workflows/release-open-issue-warning.yml
🪛 YAMLlint (1.37.1)
.github/workflows/release-open-issue-warning.yml
[error] 36-36: trailing spaces
(trailing-spaces)
[error] 38-38: trailing spaces
(trailing-spaces)
[error] 41-41: trailing spaces
(trailing-spaces)
[error] 44-44: trailing spaces
(trailing-spaces)
[error] 74-74: trailing spaces
(trailing-spaces)
[error] 76-76: trailing spaces
(trailing-spaces)
[error] 80-80: trailing spaces
(trailing-spaces)
[error] 86-86: trailing spaces
(trailing-spaces)
[error] 88-88: trailing spaces
(trailing-spaces)
[error] 94-94: trailing spaces
(trailing-spaces)
[error] 96-96: trailing spaces
(trailing-spaces)
[error] 100-100: trailing spaces
(trailing-spaces)
[error] 105-105: trailing spaces
(trailing-spaces)
[error] 114-114: trailing spaces
(trailing-spaces)
[error] 122-122: trailing spaces
(trailing-spaces)
[error] 126-126: trailing spaces
(trailing-spaces)
[error] 127-127: trailing spaces
(trailing-spaces)
[error] 128-128: trailing spaces
(trailing-spaces)
[error] 130-130: trailing spaces
(trailing-spaces)
[error] 131-131: trailing spaces
(trailing-spaces)
[error] 136-136: trailing spaces
(trailing-spaces)
[error] 143-143: trailing spaces
(trailing-spaces)
[error] 149-149: trailing spaces
(trailing-spaces)
[error] 153-153: trailing spaces
(trailing-spaces)
⏰ 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: label_project
🔇 Additional comments (1)
.github/workflows/release-open-issue-warning.yml (1)
72-75: Good: mapping X.Y to X.Y.0 milestone matches WooCommerce conventionUsing
${version}.0aligns with the repo’s milestone scheme and avoids false negatives.
| steps: | ||
| - name: Install node-ical | ||
| run: npm install node-ical | ||
| - name: Check for release events | ||
| id: check-upcoming-release-build | ||
| uses: actions/github-script@60a0d83039c74a4aee543508d2ffcb1c3799cdea #v7.0.1 | ||
| with: | ||
| script: | | ||
| const ical = require('node-ical'); |
There was a problem hiding this comment.
3p module in github-script is brittle; set up Node and load module reliably
actions/github-script often can’t require third‑party modules installed in a prior step. Make the module resolution deterministic and pin the dependency.
Apply this diff:
steps:
+ - uses: actions/setup-node@v4
+ with:
+ node-version: '20'
- - name: Install node-ical
- run: npm install node-ical
+ - name: Install node-ical
+ run: |
+ npm init -y
+ npm install node-ical@0.18.0
@@
- script: |
- const ical = require('node-ical');
+ script: |
+ const { createRequire } = require('module');
+ const requireFromWorkspace = createRequire(process.cwd() + '/package.json');
+ const ical = requireFromWorkspace('node-ical');📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| steps: | |
| - name: Install node-ical | |
| run: npm install node-ical | |
| - name: Check for release events | |
| id: check-upcoming-release-build | |
| uses: actions/github-script@60a0d83039c74a4aee543508d2ffcb1c3799cdea #v7.0.1 | |
| with: | |
| script: | | |
| const ical = require('node-ical'); | |
| steps: | |
| - uses: actions/setup-node@v4 | |
| with: | |
| node-version: '20' | |
| - name: Install node-ical | |
| run: | | |
| npm init -y | |
| npm install node-ical@0.18.0 | |
| - name: Check for release events | |
| id: check-upcoming-release-build | |
| uses: actions/github-script@60a0d83039c74a4aee543508d2ffcb1c3799cdea #v7.0.1 | |
| with: | |
| script: | | |
| const { createRequire } = require('module'); | |
| const requireFromWorkspace = createRequire(process.cwd() + '/package.json'); | |
| const ical = requireFromWorkspace('node-ical'); |
🤖 Prompt for AI Agents
In .github/workflows/release-open-issue-warning.yml around lines 15 to 23, the
current use of actions/github-script to require the third-party module
'node-ical' is unreliable because github-script cannot always access modules
installed in previous steps. To fix this, explicitly set up Node.js using
actions/setup-node before installing 'node-ical', and then run the script within
a Node.js context where the module can be reliably loaded. Also, pin the version
of 'node-ical' in the npm install command to ensure deterministic dependency
resolution.
There was a problem hiding this comment.
We use this elsewhere in workflows without any issue yet. We can review this if it becomes a problem.
There was a problem hiding this comment.
@prettyboymp Understood—let’s keep it as-is. If you want a tiny, low-impact hedge against upstream changes in this scheduled job, you could just pin the lib version:
- name: Install node-ical
run: npm install --no-save node-ical@0.18.0Happy to revisit the fuller setup-node/createRequire change only if we see flakes.
✏️ Learnings added
Learnt from: prettyboymp
PR: woocommerce/woocommerce#60272
File: .github/workflows/release-open-issue-warning.yml:15-23
Timestamp: 2025-08-08T13:52:26.382Z
Learning: Repository: woocommerce/woocommerce
Context: .github/workflows/release-open-issue-warning.yml and similar workflows
Learning: Maintainers (per prettyboymp) are fine requiring third-party modules inside actions/github-script without adding setup-node/createRequire. Prefer to keep this pattern and defer structural changes unless it demonstrably causes issues; minor safeguards like version pinning are acceptable if needed.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: jorgeatorres
PR: woocommerce/woocommerce#60262
File: .github/workflows/release-build-zip-file.yml:133-138
Timestamp: 2025-08-08T08:14:35.037Z
Learning: WooCommerce milestone convention: The woocommerce/woocommerce repository only creates GitHub milestones in the x.y.0 format, and those milestones cover RCs and patch releases for that minor train. In .github/workflows/release-build-zip-file.yml, the pre-build verification that sets `milestone="$version_prefix.0"` is intentional and should remain as-is; using `$version_prefix` alone would be incorrect for this repo.
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.
Learnt from: jorgeatorres
PR: woocommerce/woocommerce#60262
File: .github/workflows/release-build-zip-file.yml:125-130
Timestamp: 2025-08-08T08:15:10.569Z
Learning: In .github/workflows/release-build-zip-file.yml, the env var BRANCH in the verify/build jobs is set from the required `branch` input (e.g., `release/x.y`) rather than a Git ref. Using `gh pr list --search "base:$BRANCH"` is valid because `branch` is always a plain branch name in this workflow.
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: 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.
| const searchResults = await github.rest.search.issuesAndPullRequests({ | ||
| q: searchQuery, | ||
| per_page: 20, | ||
| advanced_search: true | ||
| }); | ||
|
|
There was a problem hiding this comment.
Remove unsupported advanced_search param from Search API call
Octokit’s search.issuesAndPullRequests doesn’t accept advanced_search; it may cause request validation errors.
const searchResults = await github.rest.search.issuesAndPullRequests({
q: searchQuery,
- per_page: 20,
- advanced_search: true
+ per_page: 20
});📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const searchResults = await github.rest.search.issuesAndPullRequests({ | |
| q: searchQuery, | |
| per_page: 20, | |
| advanced_search: true | |
| }); | |
| const searchResults = await github.rest.search.issuesAndPullRequests({ | |
| q: searchQuery, | |
| per_page: 20 | |
| }); |
🧰 Tools
🪛 YAMLlint (1.37.1)
[error] 86-86: trailing spaces
(trailing-spaces)
🤖 Prompt for AI Agents
In .github/workflows/release-open-issue-warning.yml around lines 81 to 86, the
call to github.rest.search.issuesAndPullRequests incorrectly includes the
unsupported parameter advanced_search. Remove the advanced_search parameter from
the API call to prevent request validation errors and ensure the search query
works correctly.
There was a problem hiding this comment.
There was a problem hiding this comment.
@prettyboymp Thanks for the context—keeping advanced_search makes sense given the current API behavior. To be robust across environments, suggest trying with advanced_search and falling back without it if the API rejects the param. Also, we can add a brief code comment with the changelog link and trim the trailing space yamllint flagged.
Here’s a drop-in update for the github-script step’s search call:
// TEMP: advanced_search is required while Issues Advanced Search is gated.
// See: https://github.blog/changelog/2025-03-06-github-issues-projects-api-support-for-issues-advanced-search-and-more/#mag-api-support-for-issues-advanced-search
const baseParams = { q: searchQuery, per_page: 20 };
let searchResults;
try {
searchResults = await github.rest.search.issuesAndPullRequests({
...baseParams,
advanced_search: true,
});
} catch (error) {
// Fallback for environments that don’t yet accept the param
if (error && (error.status === 400 || error.status === 422)) {
core.warning(`advanced_search not accepted (status ${error.status}); retrying without it for compatibility.`);
searchResults = await github.rest.search.issuesAndPullRequests(baseParams);
} else {
throw error;
}
}Minor: yamllint flagged trailing spaces around that block—worth trimming to quiet CI.
Would you like me to open a tracking issue to remove advanced_search once it’s no longer required?
✏️ Learnings added
Learnt from: prettyboymp
PR: woocommerce/woocommerce#60272
File: .github/workflows/release-open-issue-warning.yml:81-86
Timestamp: 2025-08-08T13:59:11.481Z
Learning: Repo: woocommerce/woocommerce — In .github/workflows/release-open-issue-warning.yml, the use of `advanced_search: true` in github.rest.search.issuesAndPullRequests is intentional and temporarily required per GitHub’s 2025-03-06 Issues Advanced Search API update. Prefer keeping it (with a brief inline comment and optional fallback) until GitHub removes the requirement.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: prettyboymp
PR: woocommerce/woocommerce#60272
File: .github/workflows/release-open-issue-warning.yml:15-23
Timestamp: 2025-08-08T13:52:26.382Z
Learning: Repository: woocommerce/woocommerce
Context: .github/workflows/release-open-issue-warning.yml and similar workflows
Learning: Maintainers (per prettyboymp) are fine requiring third-party modules inside actions/github-script without adding setup-node/createRequire. Prefer to keep this pattern and defer structural changes unless it demonstrably causes issues; minor safeguards like version pinning are acceptable if needed.
Learnt from: jorgeatorres
PR: woocommerce/woocommerce#60262
File: .github/workflows/release-build-zip-file.yml:133-138
Timestamp: 2025-08-08T08:14:35.037Z
Learning: WooCommerce milestone convention: The woocommerce/woocommerce repository only creates GitHub milestones in the x.y.0 format, and those milestones cover RCs and patch releases for that minor train. In .github/workflows/release-build-zip-file.yml, the pre-build verification that sets `milestone="$version_prefix.0"` is intentional and should remain as-is; using `$version_prefix` alone would be incorrect for this repo.
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.
Learnt from: jorgeatorres
PR: woocommerce/woocommerce#60262
File: .github/workflows/release-build-zip-file.yml:125-130
Timestamp: 2025-08-08T08:15:10.569Z
Learning: In .github/workflows/release-build-zip-file.yml, the env var BRANCH in the verify/build jobs is set from the required `branch` input (e.g., `release/x.y`) rather than a Git ref. Using `gh pr list --search "base:$BRANCH"` is valid because `branch` is always a plain branch name in this workflow.
Learnt from: CR
PR: woocommerce/woocommerce#0
File: .cursor/rules/generate-pr-description.mdc:0-0
Timestamp: 2025-07-21T05:22:46.426Z
Learning: Applies to .github/PULL_REQUEST_TEMPLATE.md : Preserve required markdown sections in the PR description, especially those used by automation (e.g., changelog entry details and comments). Do not remove or alter them.
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: 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.
Changes proposed in this Pull Request:
Closes WOOPLUG-5202 / #60059 .
The goal of this PR is to reduce the chances that a release DRI will need to reach out to individuals about the status of pending issues or PRs tagged for a release milestone when they are attempting to build the release.
This adds a daily workflow that will:
WooCommerce X.Y%except for feature freezes.Screenshots or screen recordings:
How to test the changes in this Pull Request:
Using the WooCommerce Testing Instructions Guide, include your detailed testing instructions:
Setup
WOOPLUG-5202/add-open-issue-for-milestone-notificationintotrunkof your fork.Testing
Release: Open Issue Warningworkflow.No Code Freeze events found in the specified range.for the workflow run.10.1.0is the milestone for10.0.WOO_RELEASE_SLACK_NOTIFICATION_CHANNELlisting the open issues.Changelog entry
Workflow change only.
Changelog Entry Details
Significance
Type
Message
Changelog Entry Comment
Comment