CI/CD Enforcement
Running phpcs only on a developer's own machine leaves an important part of the process up to that developer's initiative — moving the same checks into CI/CD is what makes them actually consistent across a team.
1. Why Local Checks Aren't Enough
A local check is easy to skip, forget, or run against the wrong ruleset by accident. A check that runs automatically in CI/CD, on every merge request, doesn't have that problem — it runs the same way regardless of who pushed the code or what they remembered to do first.
2. A Sample Pipeline
A minimal pipeline stage just runs phpcs against the same standards used locally, and fails the build if it finds a violation.
phpcs:
stage: test
script:
- vendor/bin/phpcs --standard=Drupal,DrupalPractice web/modules/custom3. Adding PHPStan and Tests
The same pipeline is the natural place for PHPStan and the project's automated tests to run too — each as its own stage, each able to fail the build independently, which makes it obvious at a glance which category of problem broke a given run.
stages:
- test
phpcs:
stage: test
script:
- vendor/bin/phpcs --standard=Drupal,DrupalPractice web/modules/custom
phpstan:
stage: test
script:
- vendor/bin/phpstan analyse web/modules/custom
phpunit:
stage: test
script:
- vendor/bin/phpunit4. Blocking the Merge
The pipeline only does its job if a failing stage actually blocks the merge — configured as a required status check, not an informational one that can be merged past. Once that's in place, code that doesn't meet the standard never reaches the main branch in the first place, which is a very different guarantee from catching it during review.
5. Pre-commit Hooks as an Earlier Layer
A pre-commit hook that runs phpcs against just the staged files adds one more layer before CI/CD even sees the change — catching a violation at the moment it's committed is a shorter feedback loop than waiting for a pipeline run, though it doesn't replace CI/CD, since a hook can always be skipped locally with --no-verify.