Gitlab CI Generator

GitLab CI/CD Pipeline Generator

Overview

Generate production-ready GitLab CI/CD pipeline configurations following current best practices, security standards, and naming conventions. All generated resources are automatically validated using the devops-skills:gitlab-ci-validator skill to ensure syntax correctness and compliance with best practices.

Trigger Phrases

Use this skill when the user asks for GitLab CI/CD generation requests such as:

• "Create a .gitlab-ci.yml for..."
• "Build a GitLab pipeline for Node/Python/Java..."
• "Add Docker build and deploy jobs in GitLab CI"
• "Set up GitLab parent-child or multi-project pipelines"
• "Include SAST/dependency scanning templates in GitLab CI"

Execution Model

Follow this deterministic flow in order:

1. Classify request complexity (targeted, lightweight, or full).
2. Load only the required reference tier for that complexity.
3. Output the matching response profile for the selected mode.
4. For complete pipeline generation, start from the closest template and customize.
5. Validate complete pipelines with strict Critical/High gates.
6. Present output with validation status and template/version notes.

If tooling is unavailable, use the documented fallback branch and report it explicitly.

Mode Routing (Quick Decision)

When uncertain on a complete-generation request, route to Full mode.

MANDATORY PRE-GENERATION STEPS

CRITICAL: Before generating any complete GitLab CI/CD pipeline, complete these steps.

Step 1: Classify Complexity (REQUIRED)

When uncertain on a complete-generation request, default to Full mode.

Step 2: Load References by Tier (REQUIRED)

Use an open/read action to load references based on the selected mode.

Targeted mode (review/Q&A/snippet/focused fix):

• Load only directly relevant references/templates for the scoped request.
• Do not enforce Full-generation Tier 1/Tier 2 checklist items.

Tier 1 (Required for complete pipeline generation in Lightweight and Full modes):

1. references/best-practices.md - baseline security, performance, naming
2. references/common-patterns.md - starting pattern selection
3. Matching template from assets/templates/:

• Docker pipelines -> assets/templates/docker-build.yml
• Kubernetes deployments -> assets/templates/kubernetes-deploy.yml
• Multi-project pipelines -> assets/templates/multi-project.yml
• Basic pipelines -> assets/templates/basic-pipeline.yml

Tier 2 (Required for Full mode; optional for Lightweight mode):

1. references/gitlab-ci-reference.md - keyword/syntax edge cases
2. references/security-guidelines.md - security-sensitive controls

Tier 3 (Conditional external docs lookup):

• Use only when local references do not cover requested features or version-specific behavior.
• Follow the lookup flow in "Handling GitLab CI/CD Documentation Lookup."

If a required local reference or template is unavailable:

• Report the exact missing path.
• Continue with available references and mark assumptions explicitly.
• Do not claim production-ready confidence until missing critical inputs are resolved.

Step 3: Confirm Understanding (EXPLICIT OUTPUT REQUIRED)

Lightweight Confirmation Mode

Use for simple requests only.

Required format:

## Reference Analysis Complete (Lightweight)

**Pattern:** [Pattern name] from common-patterns.md
**Template:** [Template file]
**Key standards to enforce:**
- [2-3 concrete standards]

Example:

## Reference Analysis Complete (Lightweight)

**Pattern:** Basic Build-Test-Deploy from common-patterns.md
**Template:** assets/templates/basic-pipeline.yml
**Key standards to enforce:**
- Pin runtime image versions (no `:latest`)
- Add explicit job timeouts
- Use `rules` instead of deprecated `only`/`except`

Full Confirmation Mode

Use for complex or security-sensitive requests.

Required format:

## Reference Analysis Complete (Full)

**Pipeline Pattern Identified:** [Pattern name] from common-patterns.md
- [Brief description of why this pattern fits]

**Best Practices to Apply:**
- [List 3-5 key best practices relevant to this pipeline]

**Security Guidelines:**
- [List security measures to implement]

**Template Foundation:** [Template file name]
- [What will be customized from this template]

Example:

## Reference Analysis Complete (Full)

**Pipeline Pattern Identified:** Docker Build + Kubernetes Deployment from common-patterns.md
- User needs containerized deployment to K8s clusters with staging/production environments

**Best Practices to Apply:**
- Pin all Docker images to specific versions (not `:latest`)
- Use caching for pip dependencies
- Implement DAG optimization with `needs` keyword
- Set explicit timeout on all jobs (15-20 minutes)
- Use `resource_group` for deployment jobs

**Security Guidelines:**
- Use masked CI/CD variables for secrets (KUBE_CONTEXT, registry credentials)
- Include container scanning with Trivy
- Never expose secrets in logs

**Template Foundation:** assets/templates/docker-build.yml + assets/templates/kubernetes-deploy.yml
- Combine Docker build pattern with K8s kubectl deployment
- Add Python-specific test jobs

Skipping confirmation is not allowed for complete pipeline generation.

Core Capabilities

1. Generate Basic CI/CD Pipelines

Create complete, production-ready .gitlab-ci.yml files with proper structure, security best practices, and efficient CI/CD patterns.

When to use:

• User requests: "Create a GitLab pipeline for...", "Build a CI/CD pipeline...", "Generate GitLab CI config..."
• Scenarios: CI/CD pipelines, automated testing, build automation, deployment pipelines

Process:

1. Understand the user's requirements (what needs to be automated)
2. Identify stages, jobs, dependencies, and artifacts
3. Use assets/templates/basic-pipeline.yml as structural foundation
4. Reference references/best-practices.md for implementation patterns
5. Reference references/common-patterns.md for standard pipeline patterns
6. Generate the pipeline following these principles:

• Use semantic stage and job names
• Pin Docker images to specific versions (not :latest)
• Implement proper secrets management with masked variables
• Use caching for dependencies to improve performance
• Implement proper artifact handling with expiration
• Use needs keyword for DAG optimization when appropriate
• Add proper error handling with retry and allow_failure
• Use rules instead of deprecated only/except
• Set explicit `timeout` for all jobs (10-30 minutes typically)