Configure a GitLab CI/CD Pipeline with Multi-Stage Builds and Caching
Create a production-grade GitLab CI/CD pipeline with parallel testing, caching, staging/production deployments, and manual approval gates.
📝 The Prompt
Generate a complete .gitlab-ci.yml configuration for a [PROJECT_TYPE] project (e.g., Python microservice, React SPA, Go CLI tool) that uses [BUILD_TOOL] and deploys to [DEPLOYMENT_TARGET] (e.g., Kubernetes, AWS ECS, Cloudflare Pages).
The pipeline should include these stages:
1. **Build Stage**:
- Install dependencies with aggressive caching (specify cache key strategy using $CI_COMMIT_REF_SLUG and lock file hashes)
- Build artifacts and pass them to subsequent stages via `artifacts: paths`
- Set timeout and resource limits appropriate for [PROJECT_SIZE]
2. **Test Stage** (parallel jobs):
- Unit tests with coverage report generation (output as Cobertura for GitLab integration)
- Linting/static analysis using [LINTER_TOOL]
- Security scanning using [SECURITY_SCANNER] (e.g., Trivy, Bandit, npm audit)
- Run these three jobs in parallel with `needs: []` where appropriate
3. **Staging Deployment**:
- Deploy to staging environment [STAGING_ENV] automatically on merge to `develop`
- Include environment URL and `environment: on_stop` for cleanup
- Run smoke tests post-deployment
4. **Production Deployment**:
- Manual approval gate (`when: manual`) for `main` branch only
- Rolling deployment with rollback strategy
- Use protected variables for [SECRETS_LIST]
5. **Global Configuration**:
- Define reusable job templates using YAML anchors or `extends`
- Add `rules` (not `only/except`) for branch-based pipeline control
- Include retry logic for flaky network-dependent jobs
- Add `interruptible: true` for non-deployment jobs
Provide the complete YAML with comments explaining each decision and a brief README section on required CI/CD variables to configure.
💡 Tips for Better Results
Always use `rules` instead of the deprecated `only/except` syntax for more flexible pipeline control. Design your cache keys around lock files (e.g., package-lock.json, Pipfile.lock) so caches invalidate only when dependencies actually change. Test your pipeline changes in a branch first using 'CI Lint' in GitLab's pipeline editor before merging.
🎯 Use Cases
DevOps engineers and team leads use this when setting up or modernizing a GitLab CI/CD pipeline that needs proper caching, parallel test execution, and safe multi-environment deployment workflows.