LEARN. PRACTICE. GROW.Concept and mechanism
A pipeline is a set of jobs with dependencies rather than merely a list of names. In ordinary GitLab stage-based configuration, later stages wait for earlier ones. With needs, a job can start when declared dependencies finish even if other earlier work continues. This provides faster feedback for independent components. Removing a necessary dependency, however, may allow testing or deployment before the correct artifact exists. Do not confuse execution order with file transfer: they need coherent configuration but are distinct problems. When changing the graph, check which jobs produce every input and which criteria still block promotion.
Guided application
In a fictional exercise, build-api and build-batch are independent and each test group needs only its own build. They can form parallel branches if integrated acceptance still waits for required results. Duration is not simply the sum of every job when real parallelism and sufficient runners exist. If a job is pending before executing any command, examine runner capacity and eligibility, tags, and permissions. Changing test code does not solve a missing executor. In GitLab, needs: [] permits immediate start; use it only when no required earlier inputs exist. Document external dependencies and avoid presenting an artifact fetch from another pipeline as an automatic guarantee that the other pipeline completed.
A job without an eligible runner does not become faster by repeating compilation.
Common pitfalls
Parallelism without dependencies; ordering as transferred file; pending as application failure.
Related topics: Integration and delivery · Artifacts and evidence · Tests and decisions
Optimize the critical path without removing required inputs or criteria.
Reference: Directed job dependencies and earlier starts · CI/CD practices 2026-09; scoped GitHub Actions GitLab Jenkins and Azure DevOps Services documentation