ci: add wp-env Playwright E2E workflow

[kzamanbd]

Summary

Adds .github/workflows/e2e.yml — runs the Playwright suite from tests/pw/ against @wordpress/env on every PR, on pushes to main, and manually via workflow_dispatch (suite: both / lite / pro).

Both tagged suites run in a single job, against one wp-env instance:

Step	Detail
Build plugin	composer install (dev mode — Mozart emits lib/packages/) + npm ci && npm run build; build/, lib/, vendor/ are gitignored, so nothing works without this
Pro mapping	.wp-env.json maps ../../../tryaura-pro (a sibling of the workspace). Checks out getdokan/tryaura-pro there when PRO_REPO_TOKEN is set, otherwise writes a stub plugin header — a missing directory makes wp-env start abort even for @lite
Run	npm run test:lite then npm run test:pro, each with its own --output dir
On failure	wp-env logs tests --no-watch, plus Playwright traces/screenshots uploaded as artifacts

Notes

• The @pro step is guarded by !cancelled(), so a @lite failure still reports both suites in one run.
• Suite order matches the npm scripts: test:lite deactivates tryaura-pro, test:pro activates it.
• @pro is skipped until the PRO_REPO_TOKEN secret is added (a repo-scoped token for getdokan/tryaura-pro). Note that repo currently has no plugin source, so the Pro run needs that code landed before it can pass.
• "core": "WordPress/WordPress" in .wp-env.json clones the full WP git history on every run — pinning it (e.g. WordPress/WordPress#6.8) would cut several minutes off CI. Left as-is here.

Test plan

• Workflow run on this PR is green for @lite
• Add PRO_REPO_TOKEN, re-run, confirm @pro executes

Summary by CodeRabbit

• New Features

  • Added automated end-to-end testing for Lite and Pro environments.
  • Added authenticated test sessions, improved test reporting, and detailed CI summaries.
  • Added automatic test environment setup and optional Pro test execution.

• Bug Fixes

  • Improved test reliability by reusing authenticated sessions and seeding required test settings.
  • Added failure logs and downloadable test reports for troubleshooting.

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds a GitHub Actions Playwright pipeline for Lite and optional Pro wp-env testing, shared admin authentication state, Gemini test-key seeding, dynamic wp-env configuration, and CI reports, summaries, diagnostics, and artifacts.

Changes

E2E CI pipeline

Layer / File(s)	Summary
CI environment and workflow wiring .github/workflows/e2e.yml, composer.json, tests/pw/.wp-env*, tests/pw/package.json, tests/pw/scripts/prepare-wp-env.mjs, .gitignore	Configures PHP and Node setup, free and optional Pro builds, Lite/Pro wp-env selection, Composer’s PHP 7.4 platform, test ports, plugin mappings, and generated-file exclusions.
Test preparation and authentication tests/pw/seed-settings.php, tests/pw/global-setup.ts, tests/pw/utils/auth.ts, tests/pw/tests/e2e/_auth.setup.ts, tests/pw/tests/e2e/*.spec.ts, tests/pw/tests/e2e/pro/*.spec.ts, tests/pw/playwright.config.ts, tests/pw/tsconfig.json	Seeds a test Gemini key, caches admin authentication for Playwright projects, switches tests to shared storage state, and removes repeated per-test login hooks.
Playwright CI reporting .github/workflows/e2e.yml, tests/pw/playwright.config.ts, tests/pw/scripts/ci-summary.mjs	Runs tagged suites, emits JSON and HTML reports, publishes GitHub step summaries, collects wp-env logs on failures, and uploads artifacts.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
  participant GitHubActions
  participant wpEnv
  participant Playwright
  participant JobSummary
  GitHubActions->>wpEnv: Prepare and start Lite or Pro environment
  GitHubActions->>Playwright: Run `@lite` and conditional `@pro` suites
  Playwright->>JobSummary: Write JSON test results
  GitHubActions->>JobSummary: Publish suite summary
  GitHubActions->>Playwright: Upload reports and test artifacts

Loading

Possibly related PRs

• getdokan/tryAura#8: Updates the settings structure used by the new E2E Gemini API-key seeding script.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 75.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: adding a wp-env-based Playwright E2E CI workflow.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ci/e2e-wp-env

---

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

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 3

🧹 Nitpick comments (2)

.github/workflows/e2e.yml (2)

24-25: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick win

Add persist-credentials: false to checkout.

Static analysis flags credential persistence here: the checked-out repo retains the GITHUB_TOKEN in git config for the rest of the job, including the untrusted npm ci / npm run build steps that follow. Add persist-credentials: false since the workflow doesn't need to push or make further authenticated git calls.

🔒 Suggested fix

             - name: Checkout code
               uses: actions/checkout@v4
+              with:
+                  persist-credentials: false

🤖 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/e2e.yml around lines 24 - 25, Update the checkout step
using actions/checkout@v4 to set persist-credentials to false, ensuring the
workflow does not retain GITHUB_TOKEN credentials for subsequent build and
dependency-installation steps.

Source: Linters/SAST tools

---

14-22: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick win

Consider declaring explicit least-privilege permissions.

The workflow has no permissions: block, so the job inherits the repo/org default GITHUB_TOKEN permissions (which may be broader than contents: read). Given this job checks out code and runs third-party install/build scripts on pull_request, scoping permissions explicitly reduces blast radius if a dependency is compromised.

🔒 Suggested fix

 jobs:
     e2e:
         name: Playwright E2E Tests
         runs-on: ubuntu-latest
         timeout-minutes: 30
+        permissions:
+            contents: read
         env:

🤖 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/e2e.yml around lines 14 - 22, Add an explicit
least-privilege permissions block to the e2e workflow, scoped to the e2e job or
workflow, granting only contents read access required by checkout. Keep the
existing Playwright E2E Tests job behavior unchanged and do not grant broader
write permissions.

🤖 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/e2e.yml:
- Around line 56-67: Update the “Checkout tryaura-pro” action to prevent the
PRO_REPO_TOKEN from being persisted in the checked-out repository’s Git
configuration, while preserving authenticated access to the private repository.
Ensure the token is unavailable on disk before subsequent composer, npm, and
build steps execute.

In `@tests/pw/.wp-env.ci.json`:
- Around line 2-6: Pin the E2E dependencies in the CI WordPress environment
configuration: replace the floating WordPress core repository reference, Basic
Auth master archive, and generic WooCommerce ZIP with immutable release versions
or commit-SHA-based URLs. Keep the existing plugin list and PHP version
unchanged while ensuring all external dependencies resolve reproducibly across
CI runs.

In `@tests/pw/global-setup.ts`:
- Around line 19-29: Update globalSetup around the seed-settings execSync call
so failures are not silently ignored: log the caught error and re-throw it, or
verify tryaura_settings.google.apiKey exists before allowing the suite to start.
Preserve the existing seeding behavior while ensuring missing or failed Gemini
setup aborts global setup.

---

Nitpick comments:
In @.github/workflows/e2e.yml:
- Around line 24-25: Update the checkout step using actions/checkout@v4 to set
persist-credentials to false, ensuring the workflow does not retain GITHUB_TOKEN
credentials for subsequent build and dependency-installation steps.
- Around line 14-22: Add an explicit least-privilege permissions block to the
e2e workflow, scoped to the e2e job or workflow, granting only contents read
access required by checkout. Keep the existing Playwright E2E Tests job behavior
unchanged and do not grant broader write permissions.

🪄 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: 7b338d37-adef-45d6-932b-295544b670c0

📥 Commits

Reviewing files that changed from the base of the PR and between 76a9ac5 and 874f2f3.

⛔ Files ignored due to path filters (2)

• composer.lock is excluded by !**/*.lock
• package-lock.json is excluded by !**/package-lock.json

📒 Files selected for processing (24)

• .github/workflows/e2e.yml
• .gitignore
• composer.json
• tests/pw/.wp-env.ci.json
• tests/pw/.wp-env.json
• tests/pw/global-setup.ts
• tests/pw/package.json
• tests/pw/playwright.config.ts
• tests/pw/scripts/ci-summary.mjs
• tests/pw/scripts/prepare-wp-env.mjs
• tests/pw/seed-settings.php
• tests/pw/tests/e2e/_auth.setup.ts
• tests/pw/tests/e2e/dashboard.spec.ts
• tests/pw/tests/e2e/enhancer.spec.ts
• tests/pw/tests/e2e/image-config.spec.ts
• tests/pw/tests/e2e/plugins-screen.spec.ts
• tests/pw/tests/e2e/pro/promo-hidden.spec.ts
• tests/pw/tests/e2e/pro/video-config.spec.ts
• tests/pw/tests/e2e/pro/video-generation.spec.ts
• tests/pw/tests/e2e/promo-banner.spec.ts
• tests/pw/tests/e2e/settings-save.spec.ts
• tests/pw/tests/e2e/sidebar-upgrade.spec.ts
• tests/pw/tsconfig.json
• tests/pw/utils/auth.ts

💤 Files with no reviewable changes (11)

• tests/pw/.wp-env.json
• tests/pw/tests/e2e/plugins-screen.spec.ts
• tests/pw/tests/e2e/promo-banner.spec.ts
• tests/pw/tests/e2e/enhancer.spec.ts
• tests/pw/tests/e2e/dashboard.spec.ts
• tests/pw/tests/e2e/pro/video-generation.spec.ts
• tests/pw/tests/e2e/pro/promo-hidden.spec.ts
• tests/pw/tests/e2e/settings-save.spec.ts
• tests/pw/tests/e2e/sidebar-upgrade.spec.ts
• tests/pw/tests/e2e/pro/video-config.spec.ts
• tests/pw/tests/e2e/image-config.spec.ts

[coderabbitai]

🔒 Security & Privacy | 🟠 Major | ⚡ Quick win

Persisted PRO_REPO_TOKEN credentials in a step that later runs untrusted build scripts.

Same artipacked finding as the main checkout, but with elevated risk: this checkout persists PRO_REPO_TOKEN — a dedicated cross-repo token — into .tryaura-pro-src/.tryaura-pro's git config, which then sits on disk while composer install, npm ci, and npm run build (line 85-87) execute arbitrary scripts from the Pro repo's dependency tree. A malicious or compromised dependency could read and exfiltrate this token.

🔒 Suggested fix

             - name: Checkout tryaura-pro
               if: env.PRO_REPO_TOKEN != ''
               uses: actions/checkout@v4
               with:
                   repository: getdokan/tryaura-pro
                   path: .tryaura-pro-src
                   token: ${{ env.PRO_REPO_TOKEN }}
+                  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.

Suggested change

	- name: Checkout tryaura-pro
	if: env.PRO_REPO_TOKEN != ''
	uses: actions/checkout@v4
	with:
	repository: getdokan/tryaura-pro
	path: .tryaura-pro-src
	token: ${{ env.PRO_REPO_TOKEN }}
	# Pro's composer.json requires php >=8.0, so it cannot be installed
	# with the 7.4 toolchain used for the free plugin (which pins 7.4 to
	# match its own minimum). Only the runner's PHP changes here — wp-env
	# serves both plugins on 8.2 regardless.
	- name: Checkout tryaura-pro
	if: env.PRO_REPO_TOKEN != ''
	uses: actions/checkout@v4
	with:
	repository: getdokan/tryaura-pro
	path: .tryaura-pro-src
	token: ${{ env.PRO_REPO_TOKEN }}
	persist-credentials: false
	# Pro's composer.json requires php >=8.0, so it cannot be installed
	# with the 7.4 toolchain used for the free plugin (which pins 7.4 to
	# match its own minimum). Only the runner's PHP changes here — wp-env
	# serves both plugins on 8.2 regardless.

🧰 Tools

🪛 zizmor (1.28.0)

[warning] 56-67: 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/e2e.yml around lines 56 - 67, Update the “Checkout
tryaura-pro” action to prevent the PRO_REPO_TOKEN from being persisted in the
checked-out repository’s Git configuration, while preserving authenticated
access to the private repository. Ensure the token is unavailable on disk before
subsequent composer, npm, and build steps execute.

Source: Linters/SAST tools

[coderabbitai]

🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== file ==="
cat -n tests/pw/.wp-env.ci.json 2>/dev/null || true

echo "== related wp-env config files =="
git ls-files | rg '(^|/)(wp-env|\.wp-env)(\.ci)?\.json$|package\.json|composer\.json|README|\.github/workflows' || true

echo "== occurrences of wp-env and PHP versions =="
rg -n '"phpVersion"|wp-env|WordPress-API/Basic-Auth|woocommerce\.zip|WordPress/WordPress' -S . --glob '!node_modules' --glob '!dist' --glob '!build' || true

echo "== package manager wp-env scripts =="
python3 - <<'PY'
import json, pathlib
for p in pathlib.Path('.').rglob('package.json'):
    if 'node_modules' in p.parts:
        continue
    try:
        data=json.load(open(p))
    except Exception:
        continue
    scripts=data.get('scripts',{})
    vals={}
    for k,v in scripts.items():
        if 'wp-env' in v or 'e2e' in k.lower() or 'playwright' in k.lower():
            vals[k]=v
    if vals:
        print(p)
        for k,v in vals.items(): print(f"  {k}: {v}")
PY

Repository: getdokan/tryAura

Length of output: 6221

---

🌐 Web query:

WordPress wp-env config core plugin ZIP URL unresolved branch master latest version deterministic

💡 Result:

In the wp-env configuration, using a ZIP URL for core, plugins, or themes is supported [1][2]. However, referencing a branch such as 'master' (e.g., 'WordPress/WordPress#master') via a ZIP URL is not natively possible because ZIP URLs are direct, static links to compressed archives and do not support Git branch referencing or dynamic resolution [1][3][4]. Deterministic behavior in wp-env is achieved by providing specific, immutable identifiers [5]. Here is the distinction between your options: 1. ZIP URLS: These are deterministic only if the URL points to a specific, versioned file (e.g., 'https://wordpress.org/wordpress-6.8.2.zip') [5][6][2]. Using a generic or mutable URL, such as 'latest.zip', is explicitly discouraged because it does not change when the underlying content changes, which can lead to stale cache issues where wp-env fails to recognize that the environment needs to be updated [5]. 2. GitHub Repository References: When using the format 'User/Repo#branch', wp-env performs a Git clone [7][4]. This is not strictly deterministic if you reference a branch like 'master' or 'trunk', as the content at that branch will change over time [1][3]. To achieve determinism with a Git source, you should reference a specific commit SHA or a version tag (e.g., 'WordPress/WordPress#6.8.2') [1][8]. If you need to test 'master' (development) versions, using a Git repository reference is the standard approach, but it will pull the latest state of that branch at the time the environment is created [1][9]. If you require a stable, deterministic environment, use a versioned ZIP URL or a specific Git tag/commit [5].

Citations:

• 1: https://github.com/WordPress/gutenberg/blob/trunk/packages/env/README.md
• 2: Env: Add support for ZIP URL sources. WordPress/gutenberg#20426
• 3: https://www.npmjs.com/package/@wordpress/env
• 4: https://make.wordpress.org/core/2020/03/03/wp-env-simple-local-environments-for-wordpress/
• 5: Use versioned WordPress.org ZIP for wp-env’s default core source WordPress/gutenberg#78942
• 6: @wordpress/env: Add support for more types of sources WordPress/gutenberg#20325
• 7: @wordpress/env: A zero-config, self contained local WordPress environment for development and testing. WordPress/gutenberg#17724
• 8: https://github.com/WordPress/gutenberg/tree/trunk/packages/env
• 9: Add .wp-env.json support to wp-env WordPress/gutenberg#20002

---

🌐 Web query:

WordPress wp-env core package plugin archive branch zip latest version

💡 Result:

In the WordPress @wordpress/env (wp-env) package, the core, plugin, and theme sources are configured via the.wp-env.json file [1][2]. The tool supports several source types for these fields, including specific branches and ZIP archives [1][2]. Core Configuration If the core field is not specified in.wp-env.json, wp-env defaults to the latest stable WordPress release [1][2]. As of recent updates, this default behavior is implemented by fetching a versioned WordPress.org ZIP file rather than cloning a Git repository, which improves performance by reducing overhead [3]. Supported Source Types You can specify the following formats for the core, plugins, or themes fields in your configuration: 1. ZIP Files: You can point to any publicly accessible WordPress ZIP archive using a URL (e.g., "https://wordpress.org/wordpress-6.8.2.zip") [1][2]. Note that using versioned ZIPs is preferred over generic "latest.zip" URLs to ensure wp-env correctly detects changes and triggers updates to the environment [3]. 2. GitHub Repositories: You can specify a repository in the format "Owner/Repo" [1][2]. You can also append a branch, tag, or commit hash using the # symbol (e.g., "WordPress/WordPress#trunk" or "WordPress/gutenberg#my-branch") [1][2]. If no branch is specified, it defaults to the repository's default branch [1][2]. 3. Local Paths: Relative or absolute paths to local directories can be used for plugins and themes (e.g., "." to mount the current directory) [1][2]. 4. SSH Repositories: SSH URLs can also be used for remote Git sources [1][2]. Environment Updates When you modify your.wp-env.json configuration, wp-env does not automatically reconfigure the environment [4]. To apply changes to sources (such as switching branches or updating a ZIP URL), you must run the following command: wp-env start --update [4] This command forces wp-env to download the updated sources and re-apply the configuration without overwriting existing content in the environment [4].

Citations:

• 1: https://github.com/WordPress/gutenberg/blob/trunk/packages/env/README.md
• 2: https://github.com/WordPress/gutenberg/tree/trunk/packages/env
• 3: Use versioned WordPress.org ZIP for wp-env’s default core source WordPress/gutenberg#78942
• 4: https://developer.wordpress.org/block-editor/reference-guides/packages/packages-env/

---

🌐 Web query:

wordpress org plugin downloader PHP 7.4 EOL plugin versions compatibility wordpress 6.9 PHP 7.4

💡 Result:

WordPress 6.9 is fully compatible with PHP 7.4 [1]. However, it is critical to note that PHP 7.4 reached its official end-of-life (EOL) on November 28, 2022, and no longer receives security updates from the PHP project [2][3][4][5]. While WordPress Core continues to support PHP 7.4 for backward compatibility purposes, this support is intended to allow older sites to function while planning their migration [1][6]. WordPress officially recommends using PHP 8.3 or greater for better performance and security [6]. Key points regarding PHP 7.4 and WordPress 6.9: 1. Security Risk: Running PHP 7.4 exposes your site to known security vulnerabilities because the version is EOL and unpatched [3][6]. 2. WordPress Support Policy: WordPress maintains support for PHP 7.4 to ensure backward compatibility [1][6], but actively encourages users to upgrade to the latest supported versions of PHP [7][6]. 3. Compatibility: As of WordPress 6.9, the core software is fully compatible with PHP 7.4 through 8.5 [1][8]. 4. Recommendation: You should upgrade to a currently supported PHP version (PHP 8.2 or higher as of July 2026) as soon as possible to maintain a secure environment [9][6]. Plugin compatibility depends on individual plugin authors, as they are not required to follow the same backward compatibility constraints as WordPress Core. If your site relies on older plugins, those plugins may have their own minimum PHP requirements that are higher than 7.4, or they may contain code that is incompatible with the newer PHP versions recommended for security [1][8]. Always check the documentation for each plugin to verify its specific PHP compatibility [6].

Citations:

• 1: https://make.wordpress.org/hosting/handbook/server-environment/
• 2: https://www.php.net/eol.php/
• 3: https://endoflife.ai/php/7.4
• 4: https://php.watch/versions/7.4/releases
• 5: https://www.zend.com/blog/planning-php-7-4-eol
• 6: https://wordpress.org/about/requirements/
• 7: https://make.wordpress.org/core/2025/11/21/php-8-5-support-in-wordpress-6-9/
• 8: https://make.wordpress.org/core/handbook/references/php-compatibility-and-wordpress-versions/
• 9: https://www.php.net/supported-versions.php

---

🌐 Web query:

WordPress wp-env config core default branch clone WordPress/WordPress

💡 Result:

In the wp-env configuration file (.wp-env.json), the core field allows you to specify a WordPress installation source [1][2]. If you provide a GitHub repository string, such as "WordPress/WordPress", you can optionally append a branch or tag using the # delimiter [1][3]. If you specify a repository but do not provide a branch or tag (e.g., "core": "WordPress/WordPress"), wp-env will automatically fall back to the repository's default branch [1][3]. For example: { "core": "WordPress/WordPress#trunk" } The above configuration would clone the trunk branch of the WordPress/WordPress repository [1][4]. If you were to use "core": "WordPress/WordPress", it would clone the default branch of that repository [1][3]. Note that when no core source is specified in the configuration (the default behavior), wp-env uses a versioned ZIP file from WordPress.org rather than a Git clone to optimize performance [5]. Explicitly providing a GitHub repository string in the core field forces wp-env to treat it as a Git source [1][3].

Citations:

• 1: https://github.com/WordPress/gutenberg/blob/trunk/packages/env/README.md
• 2: https://developer.wordpress.org/block-editor/reference-guides/packages/packages-env/
• 3: https://github.com/WordPress/gutenberg/tree/trunk/packages/env
• 4: https://www.npmjs.com/package/@wordpress/env
• 5: Use versioned WordPress.org ZIP for wp-env’s default core source WordPress/gutenberg#78942

---

Pin the E2E WordPress dependencies.

core: WordPress/WordPress clones the repo default branch, Basic Auth uses archive/master.zip, and WooCommerce uses the generic plugin ZIP; these external sources can change between CI runs. Pin them to immutable core/plugin versions or commit SHAs for reproducible E2E results.

🤖 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 `@tests/pw/.wp-env.ci.json` around lines 2 - 6, Pin the E2E dependencies in the
CI WordPress environment configuration: replace the floating WordPress core
repository reference, Basic Auth master archive, and generic WooCommerce ZIP
with immutable release versions or commit-SHA-based URLs. Keep the existing
plugin list and PHP version unchanged while ensuring all external dependencies
resolve reproducibly across CI runs.

[coderabbitai]

🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== files =="
git ls-files | rg '(^|/)(global-setup\.ts|seed-settings\.php|package\.json|playwright|pw|tests/.*)' | sed -n '1,200p'

echo "== target file =="
if [ -f tests/pw/global-setup.ts ]; then
  cat -n tests/pw/global-setup.ts
fi

echo "== seed-settings =="
if [ -f wp-content/plugins/tryaura/tests/pw/seed-settings.php ]; then
  cat -n wp-content/plugins/tryaura/tests/pw/seed-settings.php
elif [ "$(git ls-files | grep 'seed-settings\.php$' | head -n1)" ]; then
  f="$(git ls-files | grep 'seed-settings\.php$' | head -n1)"
  echo "-- found at $f --"
  cat -n "$f"
fi

echo "== usages of google.apiKey / tryaura_settings =="
rg -n "google\.apiKey|tryaura_settings|PreviewModal|Preview|enhancer=image-config|image-config" -S --glob '!node_modules' --glob '!dist' --glob '!build' . | sed -n '1,240p'

echo "== package scripts =="
if [ -f package.json ]; then
  jq '.scripts' package.json
fi

Repository: getdokan/tryAura

Length of output: 11056

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== PreviewModal key bail paths =="
rg -n "tryaura_settings|google|apiKey|new GoogleGenAI|route\(|page\.route" src/admin/enhancer/PreviewModal.tsx | sed -n '1,220p'

echo "== Read relevant PreviewModal sections =="
sed -n '290,360p' src/admin/enhancer/PreviewModal.tsx
sed -n '360,470p' src/admin/enhancer/PreviewModal.tsx
sed -n '600,720p' src/admin/enhancer/PreviewModal.tsx
sed -n '720,840p' src/admin/enhancer/PreviewModal.tsx
sed -n '880,920p' src/admin/enhancer/PreviewModal.tsx

echo "== Tests around seed/spec expectations =="
sed -n '1,140p' tests/pw/tests/e2e/enhancer.spec.ts
sed -n '1,160p' tests/pw/tests/e2e/image-config.spec.ts
sed -n '1,140p' tests/pw/tests/e2e/settings-save.spec.ts

echo "== Playwright config workers/env =="
cat -n tests/pw/playwright.config.ts | sed -n '1,220p'

echo "== Script failure model =="
node - <<'JS'
function globalSetup(exitCode=0) {
  try {
    if (exitCode !== 0) throw new Error('seed failed');
    return 'continues';
  } catch (e) {
    // best effort ignored
    return 'continues';
  }
}
console.log(JSON.stringify({
  whenSeedSucceeds: globalSetup(0),
  whenSeedFails: globalSetup(1),
}, null, 2));
JS

Repository: getdokan/tryAura

Length of output: 24395

---

Do not silently ignore Gemini seed failures.

globalSetup catches any failure from seed-settings.php and continues under workers: 1, so CI can still pass into specs that expect a key. Re-throw after logging, or verify that tryaura_settings.google.apiKey is present before starting the suite.

🧰 Tools

🪛 ast-grep (0.45.0)

[warning] Importing child_process exposes a command-execution surface; ensure any command/argument built from input is validated, and prefer execFile/spawn with an argument array over exec.
Context: import { execSync } from 'child_process';
Note: [CWE-78] Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection').

(detect-child-process-typescript)

🤖 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 `@tests/pw/global-setup.ts` around lines 19 - 29, Update globalSetup around the
seed-settings execSync call so failures are not silently ignored: log the caught
error and re-throw it, or verify tryaura_settings.google.apiKey exists before
allowing the suite to start. Preserve the existing seeding behavior while
ensuring missing or failed Gemini setup aborts global setup.