On the "Oh Dear!" blog they've written up a post sharing the Gitlab continuous integration pipeline they use for the deployment of the application. While, in their case, it's a Laravel-based application, the basics of it could be used for just about any PHP application with slight modifications.

We've been fairly public about the amount of testing we have for Oh Dear!. Freek has been showing bits and pieces on his Twitter to show the extent of that effort.

Having a huge test suite is nice, but integrating it into your development workflow is even better.

That's why we're releasing our Gitlab CI pipeline that is optimized for Laravel applications. It contains all the elements you'd expect: building (composer, yarn & webpack), database seeding, PHPUnit & copy/paste (mess) detectors & some basic security auditing of our 3rd party dependencies.

The post starts with an overview of their pipeline flow (including a graphic) showing the different stages and the steps involved in each. It then moves on to the setup of Gitlab's CI functionality using a local Gitlab runner to run the pipeline. It covers some of the issues around CPU load using Docker. Next it shares the configurations for the different stages in the flow and decisions they had to make around building assets, dependencies and caching.

On the Pine site they've posted a quick tutorial showing how to host private packages on Gitlab, in their case it's for Laravel-related packages but it would work with any project making use of Composer for package management.

When we want to restrict the access to the package we made but we don’t want to pay for a service like Private Packagist, we can use tagged: hosting gitlab private package accesstoken tutorial composer configuration

Link: https://pineco.de/hosting-private-laravel-packages-gitlab/