Adding A CI/CD process to my work flow is one of the really quick wins I do on every serious project I work on.

Whilst most of my personal work is hosted on Gitlab, a recent project I was working had its code in Bitbucket. This was my first time working with Bitbucket, so I wanted to document how I built assets, linted and ran tests using its pipelines.

What will these pipelines do?

By the end of this article you should have a working bitbucket-pipelines.yml file for your Laravel project which will do the following:

• Use composer to install your projects dependencies
• Run php-cs-fixer to enforce a code style
• Run larastan to run static analysis against the code base
• Run php-cs-fixer and larastan in parallel
• Run phpunit to run our projects test suite
• For a production build yarn run production
• Allow us to manually trigger a deployment to production using Laravel Deployer.

At our company setting up gitlab ci configuration is one of the jobs I end up doing by default.

This weekend I wrote a package to help speed that process up by generating a .gitlab-ci.yml file as well as installing some of the packages and configuration files to make the following possible:

• Setting an edbizarro docker image based on your target php version
• Handle Javascript asset compilation using NPM or Yarn
• Lint Javascript and Vue files with Eslint
• Lint php files using the laravel shift rules for PHP-Code-Fixer
• Perform static analysis with Larastan
• Run phpunit tests

The package currently provides a single artisan command to do all of the above after answering a few simple questions.

Check the repo out here:

https://github.com/talvbansal/laravel-gitlab-ci-config-generator

Recently I wrote about my current Gitlab CI process, when it came to the deployment part of the process I showed how I was handling it using a tool called Laravel deployer but I didn’t breakdown what laravel deployer was doing and how I had it configured.

The Laravel deployer docs are pretty good however I found a couple of server config issues that I always find myself referring back to when setting up auto deployment. Mostly to automatically restart Laravel Horizon and restarting Php-fpm without needing sudo privileges.

Lets imagine I was going to a set up Gitlab CI / CD for a fictional project hosted over on the fictional domain of deployer.talvbansal.com with a real repository here that is hosted on somewhere like Linode, Digital Ocean or even AWS.

Introduction

My most read articles on this blog are about Gitlab CI/CD with PHP. They cover a basic linting, testing and crude deploying process.

Today I want to look at my current CI/CD process for my Laravel projects in more depth. Currently the pipelines of my projects might vary slightly but is very similar to this:

So there are 5 main stages in the process:

• Preparation - The pulling down of dependencies and storing them in an artifact
• Syntax - Check code syntax
• Testing - Run unit tests
• Building - Build assets
• Deployment - Deploying to an appropriate server

The stages are processed in order with each stage containing one or many tasks. Should one task fails in a stage then the whole pipeline stops and is marked as failed.

To run the pipelines I make use of gitlabs free tier which gives you access to 2000 shared minutes per month as well as a runner on a server I have. More about setting that up can be found here.

For one of my recent projects I wanted to make use of the free allowance that AWS gives for SES.

One of the conditions of the SES allowance was that your calling app needs to be hosted on EC2.

I’ve not used EC2 before so I figured this would be a good way to dive into it.

Whilst I would never usually install software like composer on a production server, this was purely to test things out.

So after signing up for AWS and creating a local ubuntu server on an EC2 t2micro instance then cloning down the project I ran composer install to come across the following message:

1
2
3
4
5
6
7
8
9
10

composer install
Loading composer repositories with package information
Updating dependencies (including require-dev)

mmap() failed: [12] Cannot allocate memory

mmap() failed: [12] Cannot allocate memory
PHP Fatal error:  Out of memory (allocated 822091776) (tried to allocate 4096 bytes) in phar:///usr/local/bin/composer/src/Composer/DependencyResolver/Solver.php on line 223

Fatal error: Out of memory (allocated 822091776) (tried to allocate 4096 bytes) in phar:///usr/local/bin/composer/src/Composer/DependencyResolver/Solver.php on line 223

822091776bytes is over 800mb of memory being consumed by composer.

Introduction

I recently build my first site with Jigsaw and deployed it on Netlify.

As part of that project I had to get some data from the Instagram API and present a feed of the latest 5 images on the site.

Rather than dealing with CORS errors in javascript I wondered what I could get away with in PHP during the build phase on a statically generated site.

Would I be able to:

• Query some form of public json endpoint
• Find the urls for the latest 5 images
• Download them locally resize them for efficiency
• Display them using Jigsaw

When doing any sort of development work I’ve always preferred working on an Ubuntu machine.
Doing so has helped me understand the servers that our production code has always been run on.

Towards the end of last year I started work on a new project that made heavy use of Spatie’s Event Projector package.
Without getting into the package too much, at its core it stores the payloads of all recorded events in a JSON column within a stored_events table.

I hadn’t needed to use JSON columns before and since they were a part of MySQL 5.7 which was released in 2015 I had assumed there’d be no issues with using them.

For the most part I was right, writing unit tests with Laravel’s build in tools has made me come to love writing tests and made TDD part of my daily workflow.
However when I tried to run the same tests within Gitlabs CI/CD pipelines I saw the following:

1
2
3
4
5
6
7

PHPUnit 7.5.6 by Sebastian Bergmann and contributors.

Runtime:       PHP 7.2.15
Configuration: /builds/secret-project/phpunit.xml

 ==> Tests\Unit\ExampleTest ✓ 
"{"errors":["SQLSTATE[HY000]: General error: 1 no such function: json_extract (SQL: select * from \"stored_events\" where \"event_class\" in (App\\Events\\ClaimReported, App\\Events\\ClaimUpdatedByApp, App\\Events\\ClaimCreated, App\\Events\\ClaimUpdated, App\\Events\\ClaimUploadCompleted) and \"id\" < 1 and json_extract(\"event_properties\", '$.\"claimUuid\"') = 0dab4335-c5e8-3564-9a0a-d0537cd697f4 order by \"id\" desc limit 1)"]}"

Introduction

Recently at work we started using PHP7.2 for all of our new projects. We’d previously been using the TetraWeb docker images for our Gitlab CI needs, however they only (at the time of writing) have a docker images for versions up to PHP7.1.

I tasked one of the junior members of my team with upgrading one of our projects and came back to our repositories commit history looking like this:

Kind of ugly and not so useful when scanning our commit history.

In this article I want to show how we can test our Gitlab CI config locally whilst we’re working out how to set it up properly before we push it to Gitlab as well as keep our commit history cleaner in the process.

The PHP library Carbon is hands down my favourite way to work with dates within PHP.
When using Javascript the closes thing ive found to it is a library called Moment.js.

By default Moment.js is bundled with a plethora of locales which might not all be relavent to you or your users. In this article I want to look at how much of a size reduction we can use by stripping out unwanted locales using webpack via Laravel-Mix.