Fix GraphQl relevant missmatch while perform searching on graphql - #65
Conversation
📝 WalkthroughWalkthroughThe PR changes product search sorting from pre-build argument mutation to post-build criteria mutation, adding a descending additional-attribute sort order. It also updates the coding-standard workflow runner and action versions. ChangesProduct search ordering
Coding-standard workflow
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant SearchCriteriaBuilder
participant AddDefaultOrders
participant SortOrderBuilder
SearchCriteriaBuilder->>AddDefaultOrders: Build search criteria
AddDefaultOrders->>SortOrderBuilder: Create descending sort order
SortOrderBuilder-->>AddDefaultOrders: Return SortOrder
AddDefaultOrders-->>SearchCriteriaBuilder: Return updated SearchCriteriaInterface
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 Checkov (3.3.8).github/workflows/coding-standard.ymlTraceback (most recent call last): 🔧 PHPStan (2.2.5)Composer install failed: dependency resolution error. Check composer.json and composer.lock for version constraints. 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. Comment |
PR Summary
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/coding-standard.yml:
- Line 13: Update the actions/checkout@v7 step in the workflow to set
persist-credentials to false, ensuring checkout does not retain the
authentication token for the subsequent third-party Docker action.
- Line 14: Update the coding-standard action reference in the workflow to a
reviewed immutable commit instead of the mutable master branch, and configure
its Docker image reference with a reviewed SHA256 digest instead of the
8.4-latest tag. Preserve the existing Magento coding-standard action behavior
while ensuring both the action and container image are immutable.
In `@Plugin/DataProvider/Product/SearchCriteriaBuilder/AddDefaultOrders.php`:
- Around line 46-48: Update the unsorted criteria branch in AddDefaultOrders so
an empty getSortOrders() result initializes the sort-order list instead of
returning early, then append or assign the configured default descending order
before returning the search criteria. Preserve existing behavior for criteria
that already contain sort orders.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 217721bc-fb7f-426a-b652-c7f24a605aa1
📒 Files selected for processing (2)
.github/workflows/coding-standard.ymlPlugin/DataProvider/Product/SearchCriteriaBuilder/AddDefaultOrders.php
| steps: | ||
| - uses: actions/checkout@v2 | ||
| - uses: extdn/github-actions-m2/magento-coding-standard@master | ||
| - uses: actions/checkout@v7 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== workflow files =="
git ls-files '.github/workflows/*' || true
echo "== target workflow =="
if [ -f .github/workflows/coding-standard.yml ]; then
cat -n .github/workflows/coding-standard.yml
else
echo "missing .github/workflows/coding-standard.yml"
fi
echo "== checkout occurrences in workflow =="
if [ -f .github/workflows/coding-standard.yml ]; then
rg -n "actions/checkout|persist-credentials|git (push|pull|fetch|clone)|docker|run:" .github/workflows/coding-standard.yml
fi
echo "== changed file stat =="
git diff -- .github/workflows/coding-standard.yml | sed -n '1,160p' || trueRepository: tuyennn/magento2-outofstockatlast
Length of output: 762
🌐 Web query:
actions/checkout persist-credentials default true untrusted third party action GitHub security best practices
💡 Result:
In GitHub Actions, the actions/checkout action defaults to persist-credentials: true [1][2]. This setting configures the local Git environment by storing the authentication token (typically GITHUB_TOKEN) in a way that allows subsequent Git commands (e.g., git push, git fetch) to run automatically [1][2]. Security best practices, as documented by organizations like OWASP and security auditors, strongly recommend setting persist-credentials: false unless your workflow explicitly requires authenticated Git operations [3][4][5]. The primary security concerns regarding this default behavior include: Credential Exposure: When enabled, the authentication token is available for all subsequent steps in the same job [6][3][4]. If a compromised third-party action or malicious script runs later in the job, it can potentially access and abuse these credentials [3][4][7]. Artifact Leakage: There is a historical risk of inadvertently leaking these persisted credentials if the repository directory is bundled and uploaded as a job artifact, making the credentials accessible to anyone who can download the artifact [3][7]. While recent versions of actions/checkout have improved security by storing the token in a temporary location ($RUNNER_TEMP) rather than directly in.git/config, the underlying principle of least privilege remains paramount [1][2]. Mitigation Strategy: To adhere to security best practices, you should explicitly disable this feature in your workflow files: - uses: actions/checkout@v4 with: persist-credentials: false If your workflow requires authenticated Git operations, evaluate whether you can use minimal GITHUB_TOKEN permissions or if the task can be achieved via API calls rather than persistent Git credentials [3]. Always prioritize the principle of least privilege by restricting token permissions to the minimum necessary for the job [3][4].
Citations:
- 1: https://www.github.com/actions/checkout
- 2: https://github.com/actions/checkout/tree/v6.0.2?tab=readme-ov-file
- 3: https://actsense.dev/vulnerabilities/unsafe_checkout/
- 4: https://adaptive-enforcement-lab.com/secure/github-actions-security/third-party-actions/common-actions/
- 5: https://cheatsheetseries.owasp.org/cheatsheets/GitHub_Actions_Security_Cheat_Sheet.html
- 6: Remove
persist-credentialsor change the default tofalseactions/checkout#485 - 7: https://yossarian.net/til/post/actions-checkout-can-leak-github-credentials/
Disable checkout credential persistence.
The workflow runs a third-party Docker action after checkout, while checkout’s default token persistence is unnecessary because no later Git operation needs the token. Set persist-credentials: false for this checkout step.
Proposed fix
- uses: actions/checkout@v7
+ with:
+ persist-credentials: false📝 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.
| - uses: actions/checkout@v7 | |
| - uses: actions/checkout@v7 | |
| with: | |
| persist-credentials: false |
🧰 Tools
🪛 zizmor (1.26.1)
[warning] 13-13: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/coding-standard.yml at line 13, Update the
actions/checkout@v7 step in the workflow to set persist-credentials to false,
ensuring checkout does not retain the authentication token for the subsequent
third-party Docker action.
Source: Linters/SAST tools
| - uses: actions/checkout@v2 | ||
| - uses: extdn/github-actions-m2/magento-coding-standard@master | ||
| - uses: actions/checkout@v7 | ||
| - uses: extdn/github-actions-m2/magento-coding-standard/8.4@master |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== workflow snippet =="
if [ -f .github/workflows/coding-standard.yml ]; then
cat -n .github/workflows/coding-standard.yml | sed -n '1,80p'
else
echo "workflow not found"
fi
echo
echo "== search for mage/m2 coding standard usage =="
rg -n "magento-coding-standard|m2/magento-coding-standard|extdn/magento|coding-standard" .github README.md . 2>/dev/null | head -n 200Repository: tuyennn/magento2-outofstockatlast
Length of output: 1184
🌐 Web query:
github.com extdn github-actions-m2 magento-coding-standard/8.4 action.yaml
💡 Result:
The repository github.com/extdn/github-actions-m2 provides various GitHub Actions for Magento 2 extension testing, but it does not contain an action specifically named "magento-coding-standard/8.4" [1][2]. Regarding your query: 1. Magento Coding Standard: The ExtDN repository provides a general "magento-coding-standard" action, which typically executes the latest version of the official Magento Coding Standard [1][2]. It is not versioned by PHP version (e.g., 8.4) in the same way some other actions in the repository are [1][2]. 2. Versioned Actions: The repository does maintain versioned paths for other tools, such as "magento-mess-detector" and "magento-integration-tests," which include specific subdirectories for different PHP versions (e.g., 8.4) [1][3]. 3. PHP 8.4 Support: While the official magento/magento-coding-standard has added support for PHP 8.4 [4], if you need to run it in a workflow on PHP 8.4, it is common practice to use a standard setup (e.g., shivammathur/setup-php) to configure the environment and then execute the coding standard directly [5][6]. If you are seeing references to specific "8.4" action YAML files in that repository, they likely refer to the "magento-mess-detector" or similar tools that have implemented multi-version support, rather than the coding standard action itself [3].
Citations:
- 1: https://github.com/extdn/github-actions-m2
- 2: https://github.com/extdn/github-actions-m2/tree/refs/heads/master
- 3: extdn/github-actions-m2@b438e0c
- 4: https://github.com/magento/magento-coding-standard/releases
- 5: https://github.com/giftyhq/plugin-magento2/blob/ab473ea77a002526a8f8de8bab85c635d9082103/.github/workflows/php.yml
- 6: https://github.com/PayUMEA/gateway-magento/blob/main/.github/workflows/ci.yml
🌐 Web query:
github raw extdn github-actions-m2 magento-coding-standard action.yml 8.4
💡 Result:
The repository extdn/github-actions-m2 provides GitHub Actions for Magento 2, including support for running Magento Coding Standard [1][2]. Regarding your specific request for a version associated with "8.4," the repository recently added support for PHP 8.4 environments in its internal actions. Specifically, as of July 2026, the repository includes magento-mess-detector/8.4/action.yml and a corresponding Dockerfile:8.4 [3]. To use Magento Coding Standard via this action, the standard configuration typically follows this pattern in your .github/workflows/coding-standard.yml file [1][2][4]: jobs: static: name: M2 Coding Standard runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: extdn/github-actions-m2/magento-coding-standard@master If you require a specific PHP version for your code analysis (for example, to match a PHP 8.4 environment), note that while the magento-coding-standard action is a common entry point [1][4], other workflows in the same repository use version-specific paths for different tools (e.g., magento-integration-tests/7.4@master) [1][2]. You may need to verify if a specific magento-coding-standard/8.4 path exists or if the base magento-coding-standard@master action automatically handles the required PHP version environment [1][5]. For authoritative documentation on the Magento Coding Standard itself, it is maintained by Adobe/Magento at github.com/magento/magento-coding-standard [6]. Its current requirements support PHP 8.4 [7]. If you find the ExtDN action does not satisfy your requirements, you can also configure Magento Coding Standard manually in your workflow using setup-php, as shown in various community implementations [8].
Citations:
- 1: https://github.com/extdn/github-actions-m2
- 2: https://github.com/extdn/github-actions-m2/tree/refs/heads/master
- 3: extdn/github-actions-m2@b438e0c
- 4: https://extdn.org/2020/10/08/announcing-the-extdn-github-actions-for-m2/
- 5: https://github.com/pushonltd/module-sales-rule-extended-groups/blob/main/.github/workflows/code-analysis.yml
- 6: https://github.com/magento/magento-coding-standard
- 7: https://packagist.org/packages/magento/magento-coding-standard
- 8: https://github.com/PayUMEA/gateway-magento/blob/main/.github/workflows/ci.yml
🌐 Web query:
"extdn/github-actions-m2/magento-coding-standard/8.4" "dockerfile"
💡 Result:
There is no official Dockerfile provided directly under the path extdn/github-actions-m2/magento-coding-standard/8.4 in the ExtDN GitHub repository. The ExtDN project provides a GitHub Action that simplifies the execution of Magento Coding Standard in CI/CD pipelines [1][2]. The ExtDN Magento Coding Standard action uses pre-built Docker images hosted on Docker Hub under the repository extdn/magento-coding-standard-action [3]. These images are maintained and updated via the ExtDN GitHub Action workflow processes [4][5]. To use the Magento Coding Standard in your GitHub workflow, you should reference the action in your.github/workflows/coding-standard.yml file as follows [1][6]: name: ExtDN M2 Coding Standard on: push: branches: - master pull_request: jobs: static: name: M2 Coding Standard runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: extdn/github-actions-m2/magento-coding-standard@master If you are looking for a Docker environment to run these checks locally, you can pull the official images directly from Docker Hub [3]. As of July 2026, images are tagged by version (e.g., 8.3-latest), and you can use the following command to pull and run them [3]: docker pull extdn/magento-coding-standard-action:8.3-latest docker run --rm -v $(pwd):/app extdn/magento-coding-standard-action:8.3-latest [options] For direct usage within a project, the standard recommendation remains installing the Magento Coding Standard via Composer as a dev dependency [7]: composer require --dev magento/magento-coding-standard Then, you can execute it using vendor/bin/phpcs --standard=Magento2 [7].
Citations:
- 1: https://github.com/extdn/github-actions-m2
- 2: https://github.com/extdn/github-actions-m2/tree/refs/heads/master
- 3: https://hub.docker.com/r/extdn/magento-coding-standard-action
- 4: https://github.com/extdn/github-actions-m2/actions/runs/25273594847
- 5: https://github.com/extdn/github-actions-m2/actions
- 6: https://extdn.org/2020/10/08/announcing-the-extdn-github-actions-for-m2/index.html
- 7: https://github.com/magento/magento-coding-standard/blob/develop/README.md
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== GitHub ref/action.yml lookup =="
python3 - <<'PY'
import urllib.request
base = "https://raw.githubusercontent.com/extdn/github-actions-m2/master/magento-coding-standard/8.4/"
for path in ["action.yml", "action.yaml", "Dockerfile", "Dockerfile.84", "Dockerfile.8.4", "Dockerfile:8.4"]:
url = base + path
try:
with urllib.request.urlopen(url, timeout=20) as r:
print(f"\n--- {path} ({r.getcode()}) ---")
text = r.read().decode("utf-8", "replace")
print(text[:1200])
if "image:" in text or "docker://" in text or "-t " in text or "FROM " in text:
print("[contains docker/action image config]")
except Exception as e:
print(f"{path}: {type(e).__name__}: {e}")
PYRepository: tuyennn/magento2-outofstockatlast
Length of output: 1160
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
import urllib.request
opts = {"https_client_cert_reqs": 0}
base = "https://raw.githubusercontent.com/extdn/github-actions-m2/master/magento-coding-standard/8.4/"
for path in ["action.yml", "action.yaml", "Dockerfile", "Dockerfile.84", "Dockerfile.8.4", "Dockerfile:8.4"]:
url = base + path
try:
req = urllib.request.Request(url)
req.add_header("User-Agent", "CodeRabbit verification")
with urllib.request.urlopen(req, timeout=30) as r:
print(f"\n--- {path} ({r.getcode()}) ---")
print(r.read().decode("utf-8", "replace")[:2000])
except Exception as e:
print(f"{path}: {type(e).__name__}: {e}")
PYRepository: tuyennn/magento2-outofstockatlast
Length of output: 1125
🌐 Web query:
raw.githubusercontent.com extdn github-actions-m2 master magento-coding-standard 8.4 action.yml
💡 Result:
The resource path you specified, raw.githubusercontent.com/extdn/github-actions-m2/master/magento-coding-standard/8.4/action.yml, refers to a specific GitHub Action configuration file within the ExtDN GitHub Actions for Magento 2 repository [1][2]. The ExtDN github-actions-m2 project provides pre-configured GitHub Actions to automate various tasks, including the Magento Coding Standard check [1][2][3]. While the primary documentation typically demonstrates usage with the @master tag [1][2], the repository structure allows for referencing specific versions or sub-actions [4]. Technical context regarding this reference: - Magento Coding Standard Compatibility: The Magento Coding Standard has been updated to resolve PHP 8.4 deprecations [5]. - Usage Patterns: Users commonly reference these actions in their .github/workflows/ files [1][2][3]. Some specialized implementations have been observed referencing specific sub-paths like /magento-coding-standard/8.3@master or /magento-phpstan/8.4@master to target specific versions or tools within the ExtDN library [4]. - Alternatives: Due to the maintenance status of various community actions, some developers have shifted toward custom workflow steps that explicitly install the magento/magento-coding-standard via Composer to ensure full control over dependencies and PHP version compatibility (such as for PHP 8.4) [6][7]. If you are encountering issues using this specific path, verify that the tag or branch (e.g., master) contains the action.yml file at that exact directory structure within the extdn/github-actions-m2 repository [1][2].
Citations:
- 1: https://github.com/extdn/github-actions-m2/tree/refs/heads/master
- 2: https://github.com/extdn/github-actions-m2
- 3: https://extdn.org/2020/10/08/announcing-the-extdn-github-actions-for-m2/
- 4: https://github.com/pushonltd/module-sales-rule-extended-groups/blob/main/.github/workflows/code-analysis.yml
- 5: https://github.com/magento/magento-coding-standard/releases
- 6: https://github.com/PayUMEA/gateway-magento/blob/main/.github/workflows/ci.yml
- 7: https://github.com/PayUMEA/gateway-magento/blob/a7f0b3fb2046161c0fcc96452804ff8c9809e976/.github/workflows/ci.yml
🌐 Web query:
"https://raw.githubusercontent.com/extdn/github-actions-m2/master/magento-coding-standard/8.4/action.yml"
💡 Result:
The URL provided refers to a specific version of a GitHub Action within the extdn/github-actions-m2 repository [1][2]. This repository, maintained by the Extension Developer Network (ExtDN), provides a suite of GitHub Actions designed to assist developers in automating tasks for Magento 2 projects, including testing against the Magento Coding Standard [1][3]. The action.yml file at that location specifically defines a workflow action that executes the Magento Coding Standard, which is a set of rules for the PHP_CodeSniffer tool [1][4]. By incorporating this action into a GitHub repository's workflow (typically located in.github/workflows/coding-standard.yml), developers can automatically validate their code against Magento's official coding guidelines whenever they push code or create a pull request [1][2][3]. For context, the Magento Coding Standard is an essential tool for maintaining code quality, consistency, and compatibility within the Magento 2 ecosystem [4]. While the ExtDN action provides a convenient way to implement this, other community-maintained actions exist for similar purposes, offering various configuration options such as PHP version selection, severity adjustments, and custom rulesets [5][6][7].
Citations:
- 1: https://github.com/extdn/github-actions-m2
- 2: https://github.com/extdn/github-actions-m2/tree/refs/heads/master
- 3: https://extdn.org/2020/10/08/announcing-the-extdn-github-actions-for-m2/
- 4: https://github.com/magento/magento-coding-standard
- 5: https://github.com/marketplace/actions/magento-2-coding-standard-analysis-with-php_codesniffer
- 6: https://github.com/codemanufacture/magento-coding-standard-action
- 7: https://github.com/121eCommerceLLC/github-actions-magento-2
🌐 Web query:
site:github.com/extdn/github-actions-m2 magento-coding-standard dockerfile action.yml 8.4
💡 Result:
The extdn/github-actions-m2 repository provides GitHub Actions for Magento projects, including support for Magento Coding Standard and other static analysis tools like PHPStan [1][2]. Regarding PHP 8.4 support: 1. Docker Image Builds: The repository's workflow configuration (.github/workflows/phpstan-images.yml) explicitly includes 8.4 and 8.5 in its strategy matrix for building Docker images [3][4]. This indicates that the infrastructure for supporting PHP 8.4 exists within the project's build pipeline [3][4]. 2. Usage: You can typically reference these actions in your.github/workflows/coding-standard.yml file using syntax similar to: - uses: extdn/github-actions-m2/magento-coding-standard@master [1][2] 3. Implementation: These actions generally function by wrapping Docker containers that execute the required analysis tools [5]. When using these actions, ensure your environment is configured to handle the specific requirements of the version you are targeting [5]. If you encounter issues such as dependency errors (e.g., PHPCompatibility sniff errors), it is often due to changes in upstream dependencies within the Magento Coding Standard itself [6]. The project relies on standard GitHub Action workflows and Docker-based execution, which allows for testing against multiple PHP versions via the matrix strategy defined in the source repository [3][4].
Citations:
- 1: https://github.com/extdn/github-actions-m2/tree/refs/heads/master
- 2: https://github.com/extdn/github-actions-m2
- 3: https://github.com/extdn/github-actions-m2/blob/0829a229ddcb085ea51c512326201a161ae23ed6/.github/workflows/phpstan-images.yml
- 4: https://github.com/extdn/github-actions-m2/blob/4df8a9c4b57f32e2c877cec118962734f52d3acf/.github/workflows/phpstan-images.yml
- 5: PHPStan Actions not working for PHP 8.1 and PHP 8.2 extdn/github-actions-m2#159
- 6: ERROR: Referenced sniff "PHPCompatibility.FunctionUse.RemovedFunctions" does not exist extdn/github-actions-m2#110
🌐 Web query:
"github.com/extdn/github-actions-m2/blob/master/magento-coding-standard/8.4/action.yml"
💡 Result:
The GitHub repository extdn/github-actions-m2 provides automated GitHub Actions for Magento 2 projects, including a specific action for executing the Magento Coding Standard [1][2][3]. The specific file path you referenced, magento-coding-standard/8.4/action.yml, refers to a versioned directory within this repository that encapsulates the configuration for running the Magento Coding Standard [1]. In the context of this repository, these versioned folders (such as 8.4) typically correspond to specific configurations or releases designed to be compatible with particular PHP versions or dependency sets of the Magento Coding Standard [4][5]. Key points regarding this action: - Purpose: It allows developers to integrate static code analysis into their GitHub workflows to ensure their Magento 2 code adheres to established community coding standards [3][6]. - Usage: It is commonly invoked in a GitHub Actions workflow file (e.g.,.github/workflows/coding-standard.yml) [1][3]. - Context: The Magento Coding Standard itself is a set of rules for the PHP_CodeSniffer tool, maintained by the Magento community to ensure code quality [7][8]. If you are encountering issues using a specific version like 8.4, it may be due to dependency changes in the underlying Magento Coding Standard package, which has historically required updates to how installed_paths or other PHP_CodeSniffer configurations are managed [4]. If you are setting up a new workflow, ensure you are using the most recent configuration or referencing the current documentation in the repository's README [1][2].
Citations:
- 1: https://github.com/extdn/github-actions-m2/tree/refs/heads/master
- 2: https://github.com/extdn/github-actions-m2
- 3: https://extdn.org/2020/10/08/announcing-the-extdn-github-actions-for-m2/
- 4: ERROR: Referenced sniff "PHPCompatibility.FunctionUse.RemovedFunctions" does not exist extdn/github-actions-m2#110
- 5: https://github.com/121eCommerceLLC/github-actions-magento-2
- 6: https://extdn.org/2020/10/08/announcing-the-extdn-github-actions-for-m2/index.html
- 7: https://github.com/magento/magento-coding-standard/blob/develop/README.md
- 8: https://github.com/marketplace/actions/magento-2-coding-standard-analysis-with-php_codesniffer
🌐 Web query:
"extdn/magento-coding-standard-action:8.4-latest" "action.yml"
💡 Result:
The extdn/magento-coding-standard-action is a Docker image maintained by the Extension Developer Network (ExtDN), used primarily for running the Magento Coding Standard checks in automated environments like GitHub Actions [1]. There is no public "action.yml" file associated with the extdn/magento-coding-standard-action repository itself, as it is a Docker container image hosted on Docker Hub rather than a composite or JavaScript GitHub Action [1]. If you are looking to integrate Magento Coding Standard checks into a GitHub workflow, the recommended approach by ExtDN is to use their GitHub Actions repository, extdn/github-actions-m2 [2][3][4]. That repository provides a GitHub Action that leverages the Magento Coding Standard [2]. You can implement it in your project by creating a workflow file (e.g.,.github/workflows/coding-standard.yml) with the following step [2][5]: - uses: extdn/github-actions-m2/magento-coding-standard@master Regarding the version tag "8.4-latest" you mentioned, this corresponds to a tag for the Docker image extdn/magento-coding-standard-action on Docker Hub [1]. You can pull or reference this specific version in a Docker-based workflow using: docker pull extdn/magento-coding-standard-action:8.4-latest [1] Note that if you are using the GitHub Action directly via extdn/github-actions-m2, you typically do not need to interact with the Docker image tags manually unless you are maintaining or extending that specific action [2][1].
Citations:
- 1: https://hub.docker.com/r/extdn/magento-coding-standard-action
- 2: https://github.com/extdn/github-actions-m2
- 3: https://github.com/extdn/github-actions-m2/tree/refs/heads/master
- 4: https://p.rst.im/q/github.com/extdn/github-actions-m2
- 5: https://extdn.org/2020/10/08/announcing-the-extdn-github-actions-for-m2/
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Docker Hub tags for extdn/magento-coding-standard-action =="
python3 - <<'PY'
import json, urllib.request
url = "https://hub.docker.com/v2/repositories/extdn/magento-coding-standard-action/tags/?page_size=120"
req = urllib.request.Request(url)
req.add_header("User-Agent", "CodeRabbit verification")
with urllib.request.urlopen(req, timeout=30) as r:
data = json.load(r)
print("count:", data.get("count"))
tags = [x["name"] for x in data.get("results", [])]
for name in ["8.4-latest", "8.3-latest", "8.2-latest", "latest"]:
print(f"{name}:", name in tags)
for t in tags[:80]:
print(t)
print("...last:", tags[-20:] if len(tags) >= 20 else tags[-10:])
PY
echo
echo "== try Docker Hub image digest for 8.4-latest (no auth) =="
python3 - <<'PY'
import json, urllib.request
for api in [
"https://hub.docker.com/v2/repositories/extdn/magento-coding-standard-action/8.4-latest",
]:
try:
req = urllib.request.Request(api)
req.add_header("User-Agent", "CodeRabbit verification")
with urllib.request.urlopen(req, timeout=30) as r:
data = json.load(r)
print(api)
print(f" status: {data.get('status')}")
print(f" full_length: {data.get('full_length')}")
print(f" digest: {data.get('digest')}")
except Exception as e:
print(f"{api}: {type(e).__name__}: {e}")
PYRepository: tuyennn/magento2-outofstockatlast
Length of output: 2520
Pin the coding-standard action and container image immutably.
8.4@master follows a mutable master branch, and the 8.4 action still depends on the mutable extdn/magento-coding-standard-action:8.4-latest tag. Pin the action to a reviewed commit and the Docker image to an SHA digest so CI results cannot change without a workflow review.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/coding-standard.yml at line 14, Update the coding-standard
action reference in the workflow to a reviewed immutable commit instead of the
mutable master branch, and configure its Docker image reference with a reviewed
SHA256 digest instead of the 8.4-latest tag. Preserve the existing Magento
coding-standard action behavior while ensuring both the action and container
image are immutable.
| if (empty($sortOrders)) { | ||
| return $searchCriteria; | ||
| } |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Add the default order when criteria is unsorted.
This early return skips injection precisely when getSortOrders() is empty. Initialize the list instead, then assign the new descending order so default searches are covered.
Proposed fix
- if (empty($sortOrders)) {
- return $searchCriteria;
- }
-
$sortOrder = $this->sortOrderBuilder
->setField(AdditionalAttribute::ATTRIBUTE_CODE)
->setDirection(SortOrder::SORT_DESC)
->create();
- array_splice($sortOrders, -1, 0, [$sortOrder]);
+ if (empty($sortOrders)) {
+ $sortOrders = [$sortOrder];
+ } else {
+ array_splice($sortOrders, -1, 0, [$sortOrder]);
+ }📝 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.
| if (empty($sortOrders)) { | |
| return $searchCriteria; | |
| } | |
| $sortOrder = $this->sortOrderBuilder | |
| ->setField(AdditionalAttribute::ATTRIBUTE_CODE) | |
| ->setDirection(SortOrder::SORT_DESC) | |
| ->create(); | |
| if (empty($sortOrders)) { | |
| $sortOrders = [$sortOrder]; | |
| } else { | |
| array_splice($sortOrders, -1, 0, [$sortOrder]); | |
| } |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Plugin/DataProvider/Product/SearchCriteriaBuilder/AddDefaultOrders.php`
around lines 46 - 48, Update the unsorted criteria branch in AddDefaultOrders so
an empty getSortOrders() result initializes the sort-order list instead of
returning early, then append or assign the configured default descending order
before returning the search criteria. Preserve existing behavior for criteria
that already contain sort orders.
1 participant
Summary by CodeRabbit
Bug Fixes
Chores