VOOZH about

URL: https://deepwiki.com/MahoCommerce/maho-composer-plugin/6.2-continuous-integration-workflows

⇱ Continuous Integration Workflows | MahoCommerce/maho-composer-plugin | DeepWiki

Loading...
Loading...
Menu

Continuous Integration Workflows

Purpose and Scope

This document describes the four automated GitHub Actions workflows that ensure code quality in the Maho Composer Plugin repository. These workflows validate composer metadata, perform static analysis, check syntax, and enforce code formatting standards. Each workflow executes independently in response to Git events (push, pull request) and serves as a quality gate before code can be merged.

For static analysis configuration details, see Static Analysis with PHPStan. For development environment setup, see Development Environment Configuration.

Workflow Overview

The repository implements four distinct CI workflows, each addressing a specific quality concern:

WorkflowFilePrimary PurposeExecution Time
Composercomposer.ymlValidates package metadata integrity~30 seconds
PHPStanphpstan.ymlPerforms level 10 static analysis~2-3 minutes
PHP Syntaxsyntax-php.ymlValidates PHP syntax across versions~1-2 minutes
Line Endingsline-endings.ymlEnsures Unix line endings (LF)~10 seconds

All workflows trigger on push, pull_request, workflow_call, and workflow_dispatch events, enabling both automated and manual execution.

Sources:

CI Pipeline Architecture



Sources:



Composer Validation Workflow


The composer.yml workflow validates the integrity of composer.json and composer.lock files using Composer's built-in validation command.


Workflow Steps




Validation Command


The workflow executes composer validate --strict --no-check-all at .github/workflows/composer.yml30 which enforces:


    

  • Strict mode: Fails on warnings, not just errors
    • 

  • No check-all: Skips composer.lock validation (speeds up execution)
    • 

  • Schema validation: Ensures composer.json conforms to the JSON schema
    • 

  • Dependency integrity: Verifies package names, version constraints, and relationships
    • 



Caching Strategy


The workflow implements Composer cache optimization:


    

  1. Retrieves cache directory path using composer config cache-files-dir at .github/workflows/composer.yml20
    2. 

  2. Caches dependencies using the hash of composer.lock as the cache key at .github/workflows/composer.yml26
    3. 

  3. Falls back to OS-based cache (ubuntu-composer-*) if exact match not found at .github/workflows/composer.yml27
    4. 



This reduces subsequent workflow execution time from ~60 seconds to ~30 seconds.


Sources:



PHPStan Static Analysis Workflow


The phpstan.yml workflow performs comprehensive static analysis using PHPStan at the highest strictness level. For configuration details, see Static Analysis with PHPStan.


Dual Analysis Strategy


For pull requests, the workflow runs PHPStan twice using a matrix strategy:




The matrix configuration at .github/workflows/phpstan.yml13-18 defines:


    

  • refs: ['target-branch', 'pr-head'] - Analyzes both base and head commits
    • 

  • exclude - Skips pr-head job for non-PR events (push to branches)
    • 



Checkout Strategy


The workflow uses conditional checkout at .github/workflows/phpstan.yml28:




    

  • target-branch job: Checks out default branch (empty ref)
    • 

  • pr-head job: Checks out exact PR head SHA from github.event.pull_request.head.sha
    • 



This allows comparison between the baseline (target branch) and proposed changes (PR head).


PHP Environment Setup


The workflow uses shivammathur/setup-php@v2 at .github/workflows/phpstan.yml22-24 with:


    

  • php-version: latest - Always tests against newest stable PHP version
    • 

  • No extensions specified - Ignores platform requirements during analysis
    • 



Analysis Execution


PHPStan runs at .github/workflows/phpstan.yml45 with:




    

  • XDEBUG_MODE=off - Disables Xdebug for performance
    • 

  • -vvv - Maximum verbosity for debugging failures
    • 

  • Uses phpstan.phar from vendor/bin/ (installed via composer)
    • 



Sources:



PHP Syntax Checking Workflow


The syntax-php.yml workflow validates PHP syntax across multiple PHP versions (8.2, 8.3, 8.4) using native php -l linting.


Multi-Version Testing Matrix




The matrix at .github/workflows/syntax-php.yml14-17 defines:


    

  • fail-fast: false - All PHP versions run even if one fails
    • 

  • php-versions: ['8.2', '8.3', '8.4'] - Tests compatibility across supported versions
    • 



Changed Files Optimization


To minimize execution time, the workflow only checks modified files:


    

  1. 

    Full History Checkout: Fetches complete Git history with fetch-depth: 0 at .github/workflows/syntax-php.yml23
    

    2. 

  2. 

    Last Successful Commit: Uses SamhammerAG/last-successful-build-action@v7 at .github/workflows/syntax-php.yml25-31 to find the last successful workflow run on the main branch
    

    3. 

  3. 

    Changed Files Detection: Uses tj-actions/changed-files@v45 at .github/workflows/syntax-php.yml33-40 with:
    

      

    • base_sha: ${{ steps.last-successful-commit.outputs.sha }} - Compares against last success
      • 

    • files: **/*.{php} - Only matches PHP files
      • 

    • !.phpstorm.meta.php/* - Excludes IDE metadata
      • 

    

    4. 

  4. 

    Conditional Execution: Setup and linting steps only run if steps.changed-files.outputs.any_changed == 'true' at .github/workflows/syntax-php.yml43-51
    

    5. 



Syntax Checking Implementation


The linting loop at .github/workflows/syntax-php.yml54-65 implements:




    

  • set +e - Continues loop even if php -l fails
    • 

  • php -l "$FILE" - Lints individual file (native PHP parser)
    • 

  • Extracts line number from error message using regex
    • 

  • Outputs GitHub Actions error annotation format
    • 

  • Exits with code 255 if any file has syntax errors
    • 



PHP Configuration


The shivammathur/setup-php@v2 action at .github/workflows/syntax-php.yml42-48 configures:


    

  • php-version: ${{ matrix.php-versions }} - Matrix variable (8.2, 8.3, or 8.4)
    • 

  • ini-values: error_reporting=E_ALL, short_open_tag=Off - Strict error reporting
    • 

  • tools: none - Skips unnecessary tool installation for performance
    • 



Sources:



Line Endings Validation Workflow


The line-endings.yml workflow enforces Unix-style line endings (LF) across all files to prevent cross-platform compatibility issues.


Workflow Implementation




Detection Command


The workflow uses git grep at .github/workflows/line-endings.yml17 to detect carriage return characters:




Command breakdown:


    

  • git grep - Searches through Git-tracked files only
    • 

  • -I - Ignores binary files
    • 

  • -l - Lists only file names (not matching lines)
    • 

  • $'\r' - ANSI-C quoting for carriage return character
    • 



This approach is more efficient than checking all files on disk, as it:


    

  • Respects .gitignore patterns automatically
    • 

  • Only scans tracked files (excludes vendor/, node_modules/, etc.)
    • 

  • Works consistently across operating systems
    • 



Sources:



Workflow Execution Context


All workflows support multiple trigger mechanisms:
































TriggerPurposeUse Case
pushAutomatic validation on main branchEnsures main branch always passes
pull_requestValidation before mergeRequired check for PR approval
workflow_callReusable workflow from other workflowsEnables composite CI pipelines
workflow_dispatchManual execution via GitHub UIDebugging and maintenance


The workflow_call trigger allows these workflows to be composed into higher-level CI pipelines, enabling reuse across multiple repositories in the MahoCommerce organization.


Sources:



Caching and Performance Optimization


Three workflows implement caching strategies to reduce execution time:


Composer Cache


Both composer.yml and phpstan.yml share the same caching implementation:




Cache key structure at .github/workflows/composer.yml26:


    

  • Primary key: ubuntu-composer-<hash(composer.lock)>
    • 

  • Restore keys: ubuntu-composer- (matches any cached composer directory)
    • 



This provides:


    

  • Exact match: Restores when composer.lock unchanged
    • 

  • Partial match: Reuses older cache if lock file changed (still saves bandwidth)
    • 



Changed Files Detection


The syntax-php.yml workflow optimizes by only linting changed files:


    

  1. First run: No baseline exists, lints all PHP files (~100-200 files)
    2. 

  2. Subsequent runs: Only lints files changed since last successful run (~5-20 files)
    3. 



This reduces average execution time from ~2 minutes to ~30 seconds for typical commits.


Sources:



Integration with Development Workflow


The four CI workflows integrate into the development process as follows:




All four workflows must pass before a pull request can be merged to the main branch. This ensures:


    

  1. Composer validation prevents package metadata corruption
    2. 

  2. PHPStan analysis catches type errors and code quality issues
    3. 

  3. Syntax checking ensures compatibility across PHP 8.2, 8.3, and 8.4
    4. 

  4. Line endings check prevents CRLF line ending issues
    5. 



Developers can run checks locally before pushing:


    

  • composer validate for metadata validation
    • 

  • vendor/bin/phpstan.phar analyze for static analysis
    • 

  • php -l <file> for syntax checking
    • 

  • git grep -Il $'\r' for line ending detection
    • 



Sources: