93 lines
5.1 KiB
YAML
93 lines
5.1 KiB
YAML
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: { }
|