Skip to main content
In this guide, we’ll explore how to configure a CI pipeline with three distinct stages—build, test, and deploy—and ensure they execute in the correct order while sharing artifacts.

​
Initial Pipeline Configuration

Here’s a basic GitLab CI configuration defining three jobs:
Relying on fixed sleep intervals can lead to fragile pipelines. Instead, use proper job dependencies and artifacts to synchronize stages.

​
Job Breakdown

  • build_job_1 installs the cowsay gem, pauses for 30 seconds, then writes ASCII art into dragon.txt.
  • test_job_2 pauses for 10 seconds before verifying the file contains the keyword “dragon.”
  • deploy_job_3 outputs the contents of dragon.txt and echoes a deploy message.
By default, GitLab CI jobs run in parallel on separate runners and do not share the same workspace.

​
Observed Failures

Because test_job_2 and deploy_job_3 often start before build_job_1 finishes, they encounter missing files:
Meanwhile, build_job_1 succeeds:

​
Why Jobs Fail

  • Each job runs on a separate runner with its own workspace.
  • There’s no file sharing by default.
  • The execution order is not guaranteed without explicit dependencies.

​
Next Steps

In the next section, we’ll introduce the needs keyword and artifacts settings to:
  1. Ensure build_job_1 completes before test_job_2.
  2. Share dragon.txt as an artifact for downstream jobs.
  3. Execute deploy_job_3 only after the test stage passes.

​
References

Watch Video