Page 19 - Docker

A green test job in the pipeline overview only tells you that tests ran, not how many, which ones failed, or how well the code is actually covered. With artifacts:reports:junit and artifacts:reports:coverage_report, GitLab pulls exactly these details straight out of the test output and displays them in a structured way in the merge request widget, right down to colored lines in the diff. This article covers the concrete configuration for PHPUnit, from the correct output format setting to interpreting the results.

Anyone developing PHP inside Docker containers but still wanting to run tests directly from the IDE faces a configuration challenge: PhpStorm needs to know which PHP interpreter lives in the container, how Xdebug can be reached, and how paths are mapped between host and container. This article shows the full path.

Not every pipeline needs to be triggered by a push or a merge request. Nightly security scans, recurring cleanup jobs or regular dependency updates run best on a time based schedule, regardless of whether anyone actually committed code that day. GitLab's Scheduled Pipelines provide a cron mechanism built directly into the platform for exactly this. This article covers the setup, the cron syntax, working with pipeline variables and why a Scheduled Pipeline is fundamentally different from a classic cronjob on a server.

PhpStorm scans Docker Compose setups automatically when a project is opened and suggests run configurations for detected services. For simple setups this works remarkably well, but for multi-stage compose hierarchies like the Mark Shust setup for Magento, the automation shows clear limits.

Running docker run --memory=512m --cpus=1.5 makes Docker simply write a few values into plain text files under /sys/fs/cgroup. Once you have read those files yourself, resource limits stop looking like Docker magic and start looking like what they really are: kernel mechanics.

Containers do not talk to each other automatically. Docker networks define who can reach whom, and who cannot. Bridge networks, embedded DNS, service discovery in Compose, and secure network segmentation are the building blocks of any resilient container infrastructure.

Many Dockerfiles grow organically and accumulate patterns along the way that bloat images, double build times, or undermine the security of the container. A structured Dockerfile review surfaces these anti-patterns before they turn into a production problem.

If you only find out about quality gates in the CI pipeline, you lose minutes or hours on feedback loops that could have been resolved locally in seconds. PHPStan, PHPUnit, PHPCS and Rector can be integrated into PhpStorm so that errors become visible right at the moment you save, without ever leaving the command line.

Named volumes are sufficient for a single Docker host but hit limits as soon as containers on multiple hosts need to share the same data. Volume plugins for cloud storage such as REX-Ray, s3fs, or rclone mounts attach object storage directly as a volume, yet come with their own latency and consistency characteristics that must be understood before production use.

Many teams treat Kubernetes as the obvious choice as soon as more than one server is involved, yet very few applications actually justify the operational effort of a full cluster. Knowing the real signals for genuine need lets you make the decision based on facts instead of the latest conference talk.