Page 12 - Docker

Anyone who suddenly sees two pipelines for the same commit in GitLab CI has usually run into the difference between branch pipelines and merge request pipelines: the former test the actual push state of a branch, the latter simulate what the code would look like after a merge. This article explains the difference in detail and shows how workflow:rules reliably prevents duplicate pipelines.

Anyone who runs PHP inside a Docker container also wants PhpStorm to work with that same PHP version, for autocompletion, navigation, tests and debugging. The Docker interpreter in PhpStorm connects the IDE and the container without requiring PHP to be installed locally. This article shows how to configure it correctly.

Few sentences frustrate a development team as reliably as it works on my machine, followed by a glance at a red GitLab pipeline. Almost always the root cause is not the code itself but a difference between the local environment and the CI runner, whether a different PHP version, a missing extension, a wrong timezone, or a cache holding something different locally than in the pipeline. This article shows a systematic approach for pinpointing such discrepancies deliberately instead of guessing.

A framework upgrade, an automated refactoring, or a formatting overhaul can change tens of thousands of lines in a single merge request, even though the actual content-relevant change makes up only a fraction of that. Without countermeasures, every reviewer drowns in noise and overlooks exactly the line that carries real risk. This article shows concrete techniques, from .gitattributes for generated files through clean commit separation to GitLab-specific diff view settings, that keep large, unavoidable diffs reviewable anyway.

when: manual and allow_failure solve two different problems in GitLab CI: one controls who is allowed to trigger a step, the other whether a failure blocks the pipeline. Combined correctly, they produce safe rollout gates for production deploys and optional extra steps that never hold anyone up.

Many grown Dockerfiles install more than necessary, cache layers poorly, and rest on outdated images with known vulnerabilities. Claude analyzes existing Dockerfiles, suggests multi-stage rewrites, and explains which change has which concrete effect on build time and image size.

A Docker Compose project with a PHP container, MySQL, Redis, and Nginx is up and running quickly, but fully integrating PHPStorm so that the interpreter, debugger, database data source, and Composer all work from within the IDE requires targeted configuration in several places.

Running Terraform manually from the command line stops being reliable the moment a team shares the same infrastructure. GitLab's own Terraform integration maps plan and apply as pipeline jobs, manages state centrally, and shows changes as a diff right in the merge request before anyone touches real infrastructure.

Anyone who compiles on production servers couples the build environment and the runtime environment in a way that leads to non-reproducible deployments. Docker release images with multi-stage builds cleanly separate these phases, deliver lean artifacts, and turn every deployment into a controllable, reversible operation.

Breakpoints that never hit, Xdebug connecting but failing to find the files, deployments that land in the wrong path: almost all of these problems share the same cause, misconfigured or missing Path Mappings. Once you understand the concept, you solve these problems in minutes.