Repository navigation
Feature/setup ci cd - #3
Conversation
📝 WalkthroughWalkthroughAdds CI/CD and developer tooling: GitHub Actions workflows (CI, PHPCS, PHPUnit), Dependabot config, Composer manifest, PHPCS/phpunit configs, PHPUnit bootstrap and sample test, CONTRIBUTING/README updates, and .gitignore entries for common artifacts. Changes
Sequence Diagram(s)mermaid Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Comment |
![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
🧹 Nitpick comments (5)
.github/workflows/phpcs.yml (2)
1-39: Redundant workflow - consolidate with ci.yml.This entire workflow duplicates the
phpcsjob already defined in.github/workflows/ci.yml. Both workflows trigger on the same events and perform identical checks, which wastes CI resources and creates duplicate status checks on PRs.Consider removing this standalone workflow and relying on
ci.ymlfor PHPCS checks, or vice versa - remove the PHPCS job fromci.ymlif you prefer separate workflow files.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/phpcs.yml around lines 1 - 39, The PHPCS workflow is redundant with the phpcs job in ci.yml; remove or consolidate it by deleting this workflow file (the workflow named "PHPCS") or by removing the duplicate job "phpcs" from the other workflow so there is a single source of truth; ensure the chosen workflow still includes the same steps (Checkout code, Set up PHP, Install dependencies, Run PHPCS) and retains the run command "./vendor/bin/phpcs -n" and any required cache/setup steps to preserve behavior.
18-18: Consider pinning third-party actions to full commit SHA.The
shivammathur/setup-php@v2action is referenced by tag rather than a full commit SHA. Pinning to a specific commit SHA provides better security by ensuring the action code cannot change unexpectedly.This is a security best practice but involves a trade-off with maintainability (you'll need to manually update SHAs for security patches).
🔒 Example with pinned SHA
- name: Set up PHP - uses: shivammathur/setup-php@v2 + uses: shivammathur/setup-php@c541c155eee45413f5b09a52248675b1a2575231 # v2.31.1 with: php-version: '8.1'Note: Verify the latest commit SHA for the version you want to use.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/phpcs.yml at line 18, Update the GitHub Action reference to pin the third-party action to a specific commit SHA instead of the tag: replace the uses entry "shivammathur/setup-php@v2" with the same action referenced by its full commit SHA (e.g., "shivammathur/setup-php@<full-commit-sha>") so the workflow uses an immutable version; locate the line containing uses: shivammathur/setup-php@v2 in the workflow file and substitute the tag with the exact commit SHA for the desired v2 release..github/workflows/phpunit.yml (2)
36-36: Consider pinning third-party actions to full commit SHA.Same recommendation as for the PHPCS workflow -
shivammathur/setup-php@v2should ideally be pinned to a specific commit SHA for security.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/phpunit.yml at line 36, Replace the floating action tag shivammathur/setup-php@v2 with a pinned full commit SHA to avoid supply-chain risk: locate the uses entry referencing "shivammathur/setup-php@v2" and update it to "shivammathur/setup-php@<full-commit-sha>" (you can find the exact SHA on the action's GitHub tags or commit history), then commit the change and optionally add a short comment noting the pinned SHA for future updates.
1-73: Redundant workflow - consolidate with ci.yml.This workflow duplicates the
phpunitjob already defined in.github/workflows/ci.yml. Both use the same matrix, MySQL service configuration, and test execution steps. Consider consolidating to avoid redundant CI runs.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/phpunit.yml around lines 1 - 73, This workflow duplicates the phpunit job defined in .github/workflows/ci.yml (the job named "phpunit" / workflow name "PHPUnit"); remove or consolidate it by deleting this file and/or moving its matrix, services (mysql), setup steps and the Run PHPUnit step into the existing ci.yml job so tests run once; ensure the matrix keys (php-versions, wordpress-versions), service configuration (mysql image and env), and the Run PHPUnit invocation (composer test with WP_CORE_DIR) are preserved in ci.yml and update any workflow triggers to avoid redundant CI runs..github/workflows/ci.yml (1)
18-18: Consider pinning third-party actions to full commit SHA.The
shivammathur/setup-php@v2action at lines 18 and 67 should ideally be pinned to a specific commit SHA. This applies to all instances in this workflow.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci.yml at line 18, Replace the floating tag "shivammathur/setup-php@v2" with a pinned full commit SHA reference (e.g., "shivammathur/setup-php@<commit-sha>") for every occurrence in the workflow to ensure immutability; locate instances of the action string "shivammathur/setup-php@v2" and update both occurrences (the one at the top and the one later) to use the exact commit SHA from the action's repository, and verify no other third-party actions remain unpinned.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/ci.yml:
- Around line 38-39: The CI runs are inconsistent because ci.yml invokes
"composer phpcs" (composer script "phpcs") while phpcs.yml uses
"./vendor/bin/phpcs -n"; update the composer script named "phpcs" in
composer.json to include the -n flag (e.g., make the "phpcs" script run
"./vendor/bin/phpcs -n") or alternatively change ci.yml to call the exact same
command used in phpcs.yml so both workflows invoke "./vendor/bin/phpcs -n" and
produce identical PHPCS output.
In `@phpcs.xml.dist`:
- Around line 22-23: The comment above the testVersion config is inaccurate: it
says "Set minimum PHP version to 7.4" while the <config name="testVersion"
value="8.0-"/> sets PHP 8.0 as the minimum; update the comment to reflect the
actual configured version (e.g., "Set minimum PHP version to 8.0") so the
human-readable note matches the testVersion entry.
In `@tests/bootstrap.php`:
- Around line 41-43: The DB_PASSWORD constant is currently populated from
getenv('WP_DB_PASS') which is inconsistent with the other WP_DB_* vars and
common CI naming; update the DB_PASSWORD initialization to check for
getenv('WP_DB_PASSWORD') first and fall back to getenv('WP_DB_PASS') (and then
to empty string) so both environment names are supported (i.e., replace the
getenv('WP_DB_PASS') call used when defining DB_PASSWORD with a lookup that
prefers 'WP_DB_PASSWORD' then 'WP_DB_PASS').
---
Nitpick comments:
In @.github/workflows/ci.yml:
- Line 18: Replace the floating tag "shivammathur/setup-php@v2" with a pinned
full commit SHA reference (e.g., "shivammathur/setup-php@<commit-sha>") for
every occurrence in the workflow to ensure immutability; locate instances of the
action string "shivammathur/setup-php@v2" and update both occurrences (the one
at the top and the one later) to use the exact commit SHA from the action's
repository, and verify no other third-party actions remain unpinned.
In @.github/workflows/phpcs.yml:
- Around line 1-39: The PHPCS workflow is redundant with the phpcs job in
ci.yml; remove or consolidate it by deleting this workflow file (the workflow
named "PHPCS") or by removing the duplicate job "phpcs" from the other workflow
so there is a single source of truth; ensure the chosen workflow still includes
the same steps (Checkout code, Set up PHP, Install dependencies, Run PHPCS) and
retains the run command "./vendor/bin/phpcs -n" and any required cache/setup
steps to preserve behavior.
- Line 18: Update the GitHub Action reference to pin the third-party action to a
specific commit SHA instead of the tag: replace the uses entry
"shivammathur/setup-php@v2" with the same action referenced by its full commit
SHA (e.g., "shivammathur/setup-php@<full-commit-sha>") so the workflow uses an
immutable version; locate the line containing uses: shivammathur/setup-php@v2 in
the workflow file and substitute the tag with the exact commit SHA for the
desired v2 release.
In @.github/workflows/phpunit.yml:
- Line 36: Replace the floating action tag shivammathur/setup-php@v2 with a
pinned full commit SHA to avoid supply-chain risk: locate the uses entry
referencing "shivammathur/setup-php@v2" and update it to
"shivammathur/setup-php@<full-commit-sha>" (you can find the exact SHA on the
action's GitHub tags or commit history), then commit the change and optionally
add a short comment noting the pinned SHA for future updates.
- Around line 1-73: This workflow duplicates the phpunit job defined in
.github/workflows/ci.yml (the job named "phpunit" / workflow name "PHPUnit");
remove or consolidate it by deleting this file and/or moving its matrix,
services (mysql), setup steps and the Run PHPUnit step into the existing ci.yml
job so tests run once; ensure the matrix keys (php-versions,
wordpress-versions), service configuration (mysql image and env), and the Run
PHPUnit invocation (composer test with WP_CORE_DIR) are preserved in ci.yml and
update any workflow triggers to avoid redundant CI runs.
| - name: Run PHPCS | ||
| run: composer phpcs |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check how composer phpcs script is defined
cat composer.json | jq '.scripts.phpcs' 2>/dev/null || cat composer.json | grep -A 2 '"phpcs"'Repository: raphaelsuzuki/pmpro-level-explorer
Length of output: 85
🏁 Script executed:
# Also check the phpcs.yml workflow file
cat .github/workflows/phpcs.ymlRepository: raphaelsuzuki/pmpro-level-explorer
Length of output: 1065
🏁 Script executed:
#!/bin/bash
# Get the scripts section from composer.json
cat composer.json | jq '.scripts'Repository: raphaelsuzuki/pmpro-level-explorer
Length of output: 210
Workflows have inconsistent PHPCS output behavior.
ci.yml runs composer phpcs (which executes phpcs with no flags), while phpcs.yml runs ./vendor/bin/phpcs -n (which suppresses warnings). The -n flag changes which issues are reported, potentially causing the same code to pass one workflow but fail another. Update the phpcs script in composer.json to include the -n flag, or standardize both workflows to use the same command.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/ci.yml around lines 38 - 39, The CI runs are inconsistent
because ci.yml invokes "composer phpcs" (composer script "phpcs") while
phpcs.yml uses "./vendor/bin/phpcs -n"; update the composer script named "phpcs"
in composer.json to include the -n flag (e.g., make the "phpcs" script run
"./vendor/bin/phpcs -n") or alternatively change ci.yml to call the exact same
command used in phpcs.yml so both workflows invoke "./vendor/bin/phpcs -n" and
produce identical PHPCS output.
| if ( ! defined( 'DB_PASSWORD' ) ) { | ||
| define( 'DB_PASSWORD', getenv( 'WP_DB_PASS' ) ?: '' ); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify which DB env vars are used in workflows/scripts/docs.
rg -n --hidden -g '!vendor/**' -g '!.git/**' -C2 'WP_DB_(PASS|PASSWORD|USER|NAME|HOST)|DB_PASSWORD' .Repository: raphaelsuzuki/pmpro-level-explorer
Length of output: 872
Environment variable naming inconsistency for DB password.
Line 42 uses WP_DB_PASS, but the other database credentials follow the WP_DB_* naming pattern (WP_DB_NAME, WP_DB_USER, WP_DB_HOST). Additionally, standard WordPress testing setups and most CI tools use WP_DB_PASSWORD, not WP_DB_PASS. If only WP_DB_PASSWORD is set in the environment, authentication will silently fail with an empty password, breaking tests. Support both variable names.
🔧 Suggested fix
if ( ! defined( 'DB_PASSWORD' ) ) {
- define( 'DB_PASSWORD', getenv( 'WP_DB_PASS' ) ?: '' );
+ define( 'DB_PASSWORD', getenv( 'WP_DB_PASS' ) ?: getenv( 'WP_DB_PASSWORD' ) ?: '' );
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@tests/bootstrap.php` around lines 41 - 43, The DB_PASSWORD constant is
currently populated from getenv('WP_DB_PASS') which is inconsistent with the
other WP_DB_* vars and common CI naming; update the DB_PASSWORD initialization
to check for getenv('WP_DB_PASSWORD') first and fall back to
getenv('WP_DB_PASS') (and then to empty string) so both environment names are
supported (i.e., replace the getenv('WP_DB_PASS') call used when defining
DB_PASSWORD with a lookup that prefers 'WP_DB_PASSWORD' then 'WP_DB_PASS').
… PHPCS, and PHPUnit workflows.
…ests-config.php` file.
There was a problem hiding this comment.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@tests/wp-tests-config.php`:
- Around line 14-16: The code defines DB_PASSWORD using only
getenv('WP_DB_PASS'); update the definition to check getenv('WP_DB_PASSWORD')
first and fall back to getenv('WP_DB_PASS') so DB_PASSWORD supports both env
names; modify the DB_PASSWORD define (the define('DB_PASSWORD', ...) expression)
to use WP_DB_PASSWORD if present, otherwise use WP_DB_PASS, preserving the
existing empty-string default.
Summary by CodeRabbit
Chores
Style
Tests
Documentation