uuid:
  - value: 82f39468-d922-4a18-88d4-9ef7b8b366f1
langcode:
  - value: en
type:
  - target_id: daily_email
    target_type: node_type
    target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
revision_timestamp:
  - value: '2025-05-11T09:00:44+00:00'
revision_uid:
  - target_type: user
    target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
revision_log: {  }
status:
  - value: true
uid:
  - target_type: user
    target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
title:
  - value: |
      CI pipelines should start locally
created:
  - value: '2023-04-24T00:00:00+00:00'
changed:
  - value: '2025-05-11T09:00:44+00:00'
promote:
  - value: false
sticky:
  - value: false
default_langcode:
  - value: true
revision_translation_affected:
  - value: true
path:
  - alias: /daily/2023/04/24/ci-pipelines-should-start-locally
    langcode: en
body:
  - value: |
      <p>This week, Solomon Hykes (@solomonstre on Twitter) said:</p>

      <blockquote>
        <p>Your CI/CD pipeline should start on the developer's laptop. If it only starts after a git push, you're slowing your team down and throwing money down the drain.</p>
      </blockquote>

      <h2 id="what-does-this-mean%3F">What does this mean?</h2>

      <p>My interpretation of this is that if a pipeline is going to fail, and fail for something that could been easily tested locally, then it should have been tested and fixed locally rather than waiting to push the changes to a CI pipeline, watch it fail there, and then need to push a fix and go through the process again.</p>

      <p>In PHP projects, a common CI pipeline failure after working on a change is that PHPCS (code style) or PHPStan (static analysis) checks will fail - even though the feature, fix or refactor is working. If those checks can be run locally to shorten the feedback loop and allow the error to be fixed before the pipeline runs, it would be better to do so.</p>

      <h2 id="my-preferred-solution">My preferred solution</h2>

      <p>My approach for this is using Git hooks - specifically on a pre-push event.</p>

      <p>These are scripts that run automatically before the commits are pushed, and if it fails, it prevents the push and allows you to fix the issue.</p>

      <p>They're easy to enable using a command like <code>git config core.hooksPath .githooks</code> (assuming the scripts are in a directory called <code>.githooks</code>), and whilst I wouldn't run everything that I would in a CI pipeline, I would run tasks like PHPCS and PHPStan checks, and maybe the unit and integration tests if they're fast to run.</p>

      <p>Anything that would take a longer time to run, like functional or behavioural tests, would only be executed within the pipeline, but for common failures like PHPCS and PHPStan errors, these can be quickly fixed locally and not pushed to a CI pipeline at all.</p>

      <p><a href="https://twitter.com/solomonstre/status/1649118014594502656">Here is Solomon's original tweet</a>.</p>

              
    format: full_html
    processed: |
      <p>This week, Solomon Hykes (@solomonstre on Twitter) said:</p>

      <blockquote>
        <p>Your CI/CD pipeline should start on the developer's laptop. If it only starts after a git push, you're slowing your team down and throwing money down the drain.</p>
      </blockquote>

      <h2 id="what-does-this-mean%3F">What does this mean?</h2>

      <p>My interpretation of this is that if a pipeline is going to fail, and fail for something that could been easily tested locally, then it should have been tested and fixed locally rather than waiting to push the changes to a CI pipeline, watch it fail there, and then need to push a fix and go through the process again.</p>

      <p>In PHP projects, a common CI pipeline failure after working on a change is that PHPCS (code style) or PHPStan (static analysis) checks will fail - even though the feature, fix or refactor is working. If those checks can be run locally to shorten the feedback loop and allow the error to be fixed before the pipeline runs, it would be better to do so.</p>

      <h2 id="my-preferred-solution">My preferred solution</h2>

      <p>My approach for this is using Git hooks - specifically on a pre-push event.</p>

      <p>These are scripts that run automatically before the commits are pushed, and if it fails, it prevents the push and allows you to fix the issue.</p>

      <p>They're easy to enable using a command like <code>git config core.hooksPath .githooks</code> (assuming the scripts are in a directory called <code>.githooks</code>), and whilst I wouldn't run everything that I would in a CI pipeline, I would run tasks like PHPCS and PHPStan checks, and maybe the unit and integration tests if they're fast to run.</p>

      <p>Anything that would take a longer time to run, like functional or behavioural tests, would only be executed within the pipeline, but for common failures like PHPCS and PHPStan errors, these can be quickly fixed locally and not pushed to a CI pipeline at all.</p>

      <p><a href="https://twitter.com/solomonstre/status/1649118014594502656">Here is Solomon's original tweet</a>.</p>

              
    summary: null
field_daily_email_cta: {  }