How to validate PHP code in GitHub Actions?

[jcubic]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

I have a simple GitHub workflow that runs git pull on the server via SSH. This is a simple PHP script.

I want to add validation of the code before I update the server so I don't upload broken PHP code.

But in return, the PHP building server returns 200 even when there is an error.

Warning: PHP built-in server returns 200 even for broken scripts on this runner — HTTP code check is unreliable
Warning: PHP errors do not appear in response or log on this runner

And give errors when I try to enforce the checks.

Error: PHP error detection is completely broken on this runner — cannot validate

What can I do to validate that the PHP code actually works in GitHub Actions?

[ideepakchauhan7]

The most reliable way to validate PHP syntax in GitHub Actions is to use php -l (lint mode) — it checks for syntax errors without executing the script, so you're not fighting the built-in server's misleading 200 responses.

To lint a single file:

- name: Validate PHP syntax
  run: php -l path/to/your/script.php

To lint all PHP files recursively:

- name: Validate PHP syntax
  run: find . -name "*.php" -not -path "./vendor/*" | xargs -I{} php -l {}

php -l exits with a non-zero code on any syntax error, which will correctly fail the workflow and block the deployment.

Full example workflow:

name: Deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'

      - name: Validate PHP syntax
        run: find . -name "*.php" -not -path "./vendor/*" | xargs -I{} php -l {}

      - name: Deploy via SSH
        run: ssh user@yourserver "cd /var/www && git pull"

Why not the built-in server? php -S is meant for local dev and does not surface fatal parse errors as HTTP errors — it's not suitable for CI validation. php -l is purpose-built for exactly this use case.

If you also want to catch runtime/logic issues beyond syntax, consider adding PHPStan or Psalm as a next step.

[jcubic]

php -l will only give you errors about syntax errors. This is what AI gives me, which is not a good solution. There are multiple errors you can get from the code that are not syntax errors but logic errors. but I will check if I can use this action to detect 500 errors.

[jcubic]

I was using something similar, but it was not working on GitHub workflow. It was working locally, though.

[jcubic]

I created a syntax error to see if the job would fail. I was not able to trigger the error. It always succeeded.

[jcubic]

I don't use php -l because it will not detect logic errors. In order to find logic errors (runtime errors). You need to run the code. And I have a problem with running the code, not with the linter.

[AbhinavPabbaraju]

The issue here is not that PHP validation is “broken” on GitHub Actions — it’s that the validation strategy is incorrect.

You’re currently relying on:

HTTP response codes from PHP’s built-in server

That approach is fundamentally unreliable because:

• PHP’s built-in server returns 200 even for fatal errors
• Errors are often emitted to stderr, not HTTP output
• You’re testing runtime behavior indirectly instead of validating code itself

---

Correct approach: validate PHP at multiple layers

You should treat validation as three independent checks:

---

1. Syntax validation (fast + mandatory)

Use PHP’s built-in linter:

- name: PHP Lint
  run: find . -name "*.php" -exec php -l {} \;

This will:

• catch parse errors
• fail the workflow immediately if syntax is invalid

---

2. Static analysis (catches real bugs)

Add tools like:

• phpstan (recommended)
• psalm (alternative)

Example:

- name: Install dependencies
  run: composer install --no-progress --prefer-dist

- name: Run PHPStan
  run: vendor/bin/phpstan analyse

This catches:

• type errors
• undefined variables
• incorrect method usage

---

3. Runtime validation (actual behavior)

Instead of relying on HTTP status, explicitly fail on errors:

- name: Run PHP script with strict error handling
  run: |
    php -d display_errors=1 -d log_errors=1 -d error_reporting=E_ALL script.php

OR better — write proper tests:

- name: Run PHPUnit
  run: vendor/bin/phpunit

---

Why your current method fails

Your current pipeline:

“start PHP server → curl → check HTTP 200”

Problems:

• HTTP 200 ≠ correct execution
• Fatal errors don’t necessarily propagate to HTTP status
• Logs may not be captured in Actions runner

So even broken code can appear “successful”.

---

Recommended CI structure

A proper pipeline should look like:

jobs:
  validate:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: 8.2

      - name: Install dependencies
        run: composer install --no-progress

      - name: Lint
        run: find . -name "*.php" -exec php -l {} \;

      - name: Static Analysis
        run: vendor/bin/phpstan analyse

      - name: Tests
        run: vendor/bin/phpunit

Then only deploy if all steps pass.

---

Key takeaway

You don’t validate PHP by checking HTTP responses.

You validate it by:

1. Parsing correctness (lint)
2. Logical correctness (static analysis)
3. Behavior correctness (tests)

---

Bonus (production-grade)

If you want this to be bulletproof:

• fail on warnings: -d error_reporting=E_ALL
• convert warnings to exceptions
• enforce coverage thresholds in PHPUnit

---

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬