Module 4 Lesson 3: The 'needs' Keyword (DAG)
·DevOps

Module 4 Lesson 3: The 'needs' Keyword (DAG)

Break the stage barrier. Learn how to use 'needs' to create a Directed Acyclic Graph (DAG), allowing fast jobs to skip ahead without waiting for slow, unrelated tasks.

Module 4 Lesson 3: The 'needs' Keyword (DAG)

Traditional GitLab pipelines are Stage-Bound.

  • If you have 5 jobs in test, and 1 job in deploy...
  • The deploy job must wait for all 5 test jobs to finish.
  • If one test job takes 10 minutes, your whole pipeline is 10 minutes slower, even if that specific test has nothing to do with the deployment.

The needs keyword solves this.

1. What is a DAG?

A Directed Acyclic Graph (DAG) is a fancy way of saying: "Run this job as soon as its requirements are met, ignoring the stages."

stages:
  - build
  - test
  - deploy

build-ios:
  stage: build
  script: ./build-ios.sh

test-ios:
  stage: test
  needs: ["build-ios"] # Starts as soon as build-ios is done
  script: ./test-ios.sh

build-android:
  stage: build
  script: ./build-android.sh # Takes much longer!

In this case, test-ios starts while build-android is still running!


2. Passing Artifacts with needs

By default, needs will download the artifacts from the required job. You can be specific:

deploy-job:
  stage: deploy
  needs: 
    - job: build-job
      artifacts: true

3. When to use needs

  1. Multi-Platform: When you are building for iOS, Android, and Web at the same time.
  2. Documentation: When you want to publish docs as soon as they are linted, without waiting for the heavy backend integration tests.
  3. Fast Feedback: When you want to run a "Smoke Test" immediately after the build.

4. Why NOT use needs everywhere?

  • Complexity: It makes the "Pipeline Graph" harder to follow.
  • Debugging: If a job doesn't start, you have to trace back through a "Web" of requirements rather than just looking at the stage list.

Exercise: The Fast Lane

  1. Create a pipeline with 3 stages.
  2. Add a slow-build job (Stage 1, script: sleep 60).
  3. Add a fast-build job (Stage 1, script: sleep 5).
  4. Add a fast-test job (Stage 2) that needs fast-build.
  5. Watch the pipeline execution. Does fast-test start while slow-build is still working?
  6. How much total time did you save in this specific run?

Summary

The needs keyword transforms your pipeline from a "Sequential Queue" into an "Intelligent Network." By mapping out the true dependencies of your jobs, you ensure that your developers get their results (and their software) as fast as mathematically possible.

Next Lesson: External events: Pipeline triggers and API.

Subscribe to our newsletter

Get the latest posts delivered right to your inbox.

Subscribe on LinkedIn