Commit 155aaa2f69 for woocommerce
commit 155aaa2f699c8cddcba0941c67184c3ab458d4b8
Author: Eric Binnion <ericbinnion@gmail.com>
Date: Tue Nov 25 10:06:29 2025 -0600
Actions: Update backwards compatibility to use only inline comments (#62055)
* CI: Update backwards compatibility to use inline comments
* Improve prompt for minimizing duplicate inline comments as well as comment content
* Improve conditional of forked pr conditional to account for null
diff --git a/.github/workflows/backwards-compatibility-review.yml b/.github/workflows/backwards-compatibility-review.yml
index 895c117138..ab1f9acf25 100644
--- a/.github/workflows/backwards-compatibility-review.yml
+++ b/.github/workflows/backwards-compatibility-review.yml
@@ -10,62 +10,78 @@ concurrency:
jobs:
review-with-tracking:
+ if: |
+ github.event.pull_request.draft == false &&
+ github.event.pull_request.head.repo != null &&
+ github.event.pull_request.head.repo.full_name == github.repository
runs-on: ubuntu-latest
timeout-minutes: 20
permissions:
contents: read
pull-requests: write
- issues: write
id-token: write
+
steps:
- name: Checkout repository
uses: actions/checkout@v5
with:
fetch-depth: 0
- - name: PR Review with Progress Tracking
+ - name: PR Review with Progress Tracking (inline-only)
uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
-
- # Enable progress tracking
- track_progress: true
-
- # update a single comment, instead of posting a new one on each push
- use_sticky_comment: true
-
- # Your custom review instructions
prompt: |
+ WooCommerce/WordPress Backwards Compatibility
+
REPO: ${{ github.repository }}
- PR NUMBER: ${{ github.event.pull_request.number }}
+ PR: #${{ github.event.pull_request.number }}
+
+ OBJECTIVE
+ Identify ONLY backwards compatibility risks and missing deprecations across PHP, JS/Blocks, REST, templates, and data contracts.
- PRIMARY OBJECTIVE: Backwards Compatibility (BC) Review for WooCommerce/WordPress
+ OUTPUT RULES
+ - At most ONE inline comment per (file, original_line, topic). Merge points into a single comment.
+ - Insert a hidden marker in every inline comment to enable reliable dedup across pushes:
+ <!-- wc-bc:path={path};ol={original_line};topic={topic} -->
+ - Before creating a comment, list existing PR review comments and search by this marker. If a matching comment exists, UPDATE it via PATCH to merge new details; do not post a new one.
+ - If the marker cannot be constructed (e.g., missing original_line), fallback to (file, line, topic) matching.
- Only report on BC risks and required deprecations. Ignore styling, formatting, comments, and pure test/doc changes unless they mask a BC concern.
+ INLINE COMMENT TEMPLATE (use exactly with blank lines between sections)
+ ```
+ Backwards Compatibility Review
- Output format (strict):
- - Summary: Overall risk [None|Low|Medium|High] and a 2 to 4 sentence rationale.
- - Testing Focus: targeted regression areas (e.g., checkout, gateways, subscriptions) with concrete steps.
- - Confidence: a percentage and one-sentence justification.
- - Apart from the "Overall risk" section, please use collapsed sections for details, the overall Github comment should be short and readable at first glance.
+ **Why breaking:** <1-3 sentences>
- Scope to analyze (but not limited to):
- - PHP: public/protected API signature/visibility changes; default param or type-hint changes; thrown exceptions; removed/renamed hooks (`do_action`, `apply_filters`); template changes under `templates/**`; REST params/response shapes; DB/schema/options changes; global constants/vars; composer constraints.
- - JS/Blocks: block names/attributes; script/style handle names, dependencies, and load order; REST schemas; data-store selectors/actions; settings/options keys.
- - Ecosystem impact: payment gateways, popular Woo extensions (Subscriptions/Bookings/Memberships), themes customizing templates, custom checkout flows.
+ **Migration:** <specific code or steps>
- Method:
- - Prefer exact citations with file:line for every item (from the diff and repo).
- - Provide mitigation or migration guidance for each breaking/deprecation.
- - If uncertain, state what evidence is missing and rate likelihood.
- - Use inline comments for line-specific concerns and one top-level summary comment.
+ **Deprecation:** <version plan, shim, notices>
+ ```
+ <!-- wc-bc:path={path};ol={original_line};topic={topic} -->
- Ignore/limit noise and cost:
- - Exclude generated/binary/third-party content (e.g., `vendor/**`, `node_modules/**`, `build/**`, `dist/**`, `*.min.*`, translations `*.mo`/`*.po`).
- - Focus on files changed in this PR and related API touch points.
+ ANALYSIS BOUNDARIES
+ Include:
+ - PHP: public/protected signature or visibility changes; default param changes; return/param type-hints; adding `declare(strict_types=1)` to existing files; thrown exception class changes; removed/renamed hooks (`do_action`, `apply_filters`); `templates/**` contract changes; REST route/param/response changes; DB/schema/options; globals/constants; composer constraints.
+ - JS/Blocks: block names/attributes; script/style handle names, dependencies, and load order; `wp.data` selectors/actions; REST schemas; settings/option keys.
+ Exclude:
+ - `vendor/**`, `node_modules/**`, `build/**`, `dist/**`, `**/*.min.*`, `**/*.map`, translations `**/*.po` `**/*.mo`, images/binaries, generated artifacts, `tests/**`.
- If no BC issues are found, explicitly state: "No breaking changes detected" and explain why, including deprecation sufficiency and ecosystem considerations.
+ METHOD
+ - Cite exact `file:line` for every claim (from the PR diff and repository state).
+ - For each risky change propose: non-breaking approach, shim, and staged deprecation timeline.
+ - Do not duplicate an existing equivalent "[Backwards Compatibility]" inline comment on the same line/context.
+ - For each potential comment determine variables:
+ - PATH: the file path of the change
+ - LINE: the target line number in the current diff
+ - ORIGINAL_LINE: the stable original line if available; otherwise use LINE
+ - TOPIC: one of the predefined Topic values
+ - Query existing review comments and find a match using the hidden marker first, with path and topic, preferring `original_line` and falling back to `line`:
+ gh api "repos/${REPO}/pulls/${PR}/comments?per_page=100" --paginate \
+ --jq \
+ "map(select(.path==\"${PATH}\" and ((.original_line==${ORIGINAL_LINE}) or (.line==${LINE})) and (.body|contains(\"wc-bc:path=${PATH};\") and (.body|contains(\"topic=${TOPIC}\")) ))) | first | .id"
+ - If an ID is returned, PATCH that comment to merge/append updated guidance instead of posting a new one:
+ gh api repos/${REPO}/pulls/comments/${ID} -X PATCH -f body@updated_body.md
+ - Otherwise, post a single merged comment for that (file, original_line, topic).
- # Tools for comprehensive PR review
- claude_args: |
- --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*),Bash(gh api:*),Bash(git show:*),Bash(git diff:*),Bash(git ls-files:*),Bash(git grep:*),Bash(rg *)"
+ claude_args: >
+ --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr diff:*),Bash(gh pr view:*),Bash(gh api:*),Bash(git show:*),Bash(git diff:*),Bash(git ls-files:*),Bash(git grep:*)"