🦊 GitLab CI: Achieving 3-Second Jobs on Million-Line Codebases

Initial thoughts Prerequisites: The right foundation Classic optimizations first Extreme optimizations: going beyond Breaking down the 3-second job Job execution on a well-sized shell runner Phase 1: Waiting (~0s) Phase 2: Server (~0s) Phase 3: OS / Shell (~1s) Phase 4: Git Clone/Fetch (~1s) Phase 5: Cache (~0s) Phase 6: Artifacts (none) Phase 7: Script (~1s) Phase 8: Termination (~0s) Final timing breakdown Real project results Wrapping up Further reading Initial thoughts Is it really possible to run GitLab CI jobs in just 3 seconds on a codebase with several million lines of code? The answer is yes, and this article will show you how. After comparing different runner topologies in GitLab Runners: Which Topology for Fastest Job Execution? , we found that Shell and Docker executors offer the best potential for fast job execution. Now it's time to push those runners to their absolute limits with extreme optimizations. This isn't about theoretical performance—these are real, production r