Using GitLab Parent‑Child Pipelines and Dynamic Pipeline Generation

GitLab introduces improvements to parent‑child pipelines to help scale applications and repository structures, especially for monorepos where a single .gitlab-ci.yml becomes hard to manage. By allowing child pipelines to run concurrently, complex pipelines can be broken into multiple, visualizable stages.

The tutorial shows how to create a simple C++ program and configure two child pipelines—one for Windows and one for Linux—using the include and trigger keywords. Both jobs run in a triggers stage and are guarded by rules that fire only when files under cpp_app/ change.

Example Windows child pipeline ( .win-gitlab-ci.yml ) uses a GCC image, installs mingw-w64 , compiles the program to helloGitLab.exe , and stores the artifact. The Linux child pipeline ( .linux-gitlab-ci.yml ) compiles to a native binary and also publishes the artifact.

Parent pipelines can also use strategy: depend so that the parent’s status reflects the success of its children. Up to three child pipelines can be triggered using standard include mechanisms.

Beyond static child pipelines, the article demonstrates dynamic generation of child configuration files. A setup stage runs a Ruby script ( write-config.rb ) that writes .linux-gitlab-ci.yml and .win-gitlab-ci.yml based on templates, then stores them as artifacts.

Subsequent trigger jobs in the triggers stage consume these artifacts and launch the generated pipelines, achieving the same effect as the static examples but with configuration generated at runtime.

The article concludes that these techniques allow teams to manage large, multi‑service projects with clearer CI/CD pipelines, better performance, and easier maintenance.