home / skills / akin-ozer / cc-devops-skills / gitlab-ci-validator

gitlab-ci-validator skill

/devops-skills-plugin/skills/gitlab-ci-validator

This skill validates and secures GitLab CI/CD configurations by linting, testing, and auditing pipelines for best practices and security.

npx playbooks add skill akin-ozer/cc-devops-skills --skill gitlab-ci-validator

Review the files below or copy the command above to add this skill to your agents.

Files (20)
SKILL.md
20.5 KB
---
name: gitlab-ci-validator
description: Comprehensive toolkit for validating, linting, testing, and securing GitLab CI/CD pipeline configurations. Use this skill when working with GitLab CI/CD pipelines, validating pipeline syntax, debugging configuration issues, or implementing best practices.
---

# GitLab CI/CD Validator

Comprehensive toolkit for validating, linting, testing, and securing GitLab CI/CD pipeline configurations (.gitlab-ci.yml files). Use this skill when working with GitLab CI/CD pipelines, validating pipeline syntax, debugging configuration issues, implementing best practices, or performing security audits.

## When to Use This Skill

Use the **gitlab-ci-validator** skill in the following scenarios:

- ✅ Working with `.gitlab-ci.yml` files
- ✅ Validating GitLab CI/CD pipeline syntax and structure
- ✅ Debugging pipeline configuration errors
- ✅ Implementing GitLab CI/CD best practices
- ✅ Performing security audits on pipeline configurations
- ✅ Checking for hardcoded secrets or credentials
- ✅ Optimizing pipeline performance (cache, DAG, parallel execution)
- ✅ Ensuring compliance with security standards
- ✅ Code review of GitLab CI/CD configurations
- ✅ Migrating or refactoring pipeline configurations

## Features

### 1. Syntax Validation
- ✅ YAML syntax checking
- ✅ GitLab CI schema validation
- ✅ Required fields verification
- ✅ Job naming conventions
- ✅ Stage reference validation
- ✅ Dependency validation (needs, dependencies, extends)
- ✅ Rules and conditional logic validation
- ✅ Artifact and cache configuration validation

### 2. Best Practices Checking
- ✅ Cache usage for dependency installation
- ✅ Artifact expiration settings
- ✅ Proper use of 'needs' vs 'dependencies'
- ✅ Use of 'rules' vs deprecated 'only'/'except'
- ✅ Interruptible job configuration
- ✅ Retry configuration
- ✅ Timeout settings
- ✅ Docker image version pinning
- ✅ DAG (Directed Acyclic Graph) optimization opportunities
- ✅ Parallel execution opportunities
- ✅ Resource optimization (resource_group)
- ✅ Environment configuration
- ✅ Template usage with 'extends'

### 3. Security Scanning
- ✅ Hardcoded secrets and credentials detection
- ✅ Secrets exposure in logs
- ✅ Insecure Docker image usage (:latest tags)
- ✅ Dangerous script patterns (curl | bash, eval, chmod 777)
- ✅ Insecure dependency installation
- ✅ Variable security (masked, protected variables)
- ✅ Include security (unpinned references)
- ✅ Artifact security (overly broad paths)
- ✅ SSL/TLS verification bypasses
- ✅ Debug mode warnings
- ✅ **NEW:** Component include validation (GitLab 17.0+)
- ✅ **NEW:** All include types (component, project, remote, local, template)

## Core Validation Workflow

Follow this workflow when validating GitLab CI/CD pipelines to catch issues early and ensure configuration quality:

### 1. Initial Validation (Syntax & Schema)

Start with syntax validation to catch YAML errors, schema violations, and structural issues:

```bash
# Quick syntax check (fastest)
bash scripts/validate_gitlab_ci.sh --syntax-only .gitlab-ci.yml
```

**What it checks:**
- YAML syntax and structure
- GitLab CI schema compliance
- Job definitions and required fields
- Stage references and dependencies
- Include configurations (component, project, remote, local, template)
- Component format and version validation
- Circular dependency detection
- GitLab limits (500 jobs max, 255 char job names, 50 max needs, 100 max components)

**Action:** Fix all syntax errors before proceeding.

### 2. Best Practices Review

After passing syntax validation, check for optimization opportunities and best practices:

```bash
# Best practices analysis
bash scripts/validate_gitlab_ci.sh --best-practices .gitlab-ci.yml
```

**What it checks:**
- Cache usage for dependency installation
- Artifact expiration settings
- DAG optimization with 'needs'
- Parallel execution opportunities
- Image version pinning
- Deprecated syntax (only/except → rules)
- Resource optimization
- Missing timeouts and retries

**Action:** Review suggestions and apply relevant optimizations.

### 3. Security Audit

Perform a comprehensive security scan to identify vulnerabilities:

```bash
# Security scan
bash scripts/validate_gitlab_ci.sh --security-only .gitlab-ci.yml
```

**What it checks:**
- Hardcoded secrets and credentials
- Component security (version pinning, trusted sources)
- Remote include integrity
- Insecure script patterns (curl | bash, eval)
- SSL/TLS verification bypasses
- Dangerous file permissions
- Artifact security
- Variable masking
- Path traversal in local includes

**Action:** Fix all critical and high-severity security issues immediately.

### 4. Local Pipeline Testing (Optional)

For complex changes, test pipeline execution locally before pushing:

```bash
# Install gitlab-ci-local first (requires Docker and Node.js)
bash scripts/install_tools.sh

# Test pipeline locally
gitlab-ci-local

# Or via the validator script
bash scripts/validate_gitlab_ci.sh --test-only .gitlab-ci.yml
```

**What it does:**
- Simulates pipeline execution locally
- Tests job ordering and dependencies
- Validates environment setup
- Catches runtime errors early

**Note:** Requires Docker and gitlab-ci-local installation.

### 5. Complete Validation

Run all validators together for comprehensive checking:

```bash
# Full validation pipeline
bash scripts/validate_gitlab_ci.sh .gitlab-ci.yml

# Strict mode (fail on warnings)
bash scripts/validate_gitlab_ci.sh .gitlab-ci.yml --strict
```

### Workflow Summary

```
┌─────────────────────────────────────────────────────────────┐
│ 1. Syntax Validation (Required)                             │
│    ├─ YAML structure                                         │
│    ├─ Schema compliance                                      │
│    ├─ Include validation (component, project, etc.)         │
│    └─ Component format & version                            │
│         ↓                                                    │
│    Fix errors → Proceed                                      │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│ 2. Best Practices (Recommended)                             │
│    ├─ Cache optimization                                     │
│    ├─ DAG opportunities                                      │
│    ├─ Image pinning                                          │
│    └─ Resource optimization                                  │
│         ↓                                                    │
│    Review & apply → Proceed                                  │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│ 3. Security Audit (Required)                                │
│    ├─ Hardcoded secrets                                     │
│    ├─ Component security                                     │
│    ├─ Include integrity                                      │
│    └─ Dangerous patterns                                     │
│         ↓                                                    │
│    Fix critical issues → Proceed                             │
└─────────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────────┐
│ 4. Local Testing (Optional)                                 │
│    └─ gitlab-ci-local execution                             │
│         ↓                                                    │
│    Test & verify → Push                                      │
└─────────────────────────────────────────────────────────────┘
```

## Usage

### Basic Validation

To validate a GitLab CI/CD configuration file:

```bash
bash .claude/skills/gitlab-ci-validator/scripts/validate_gitlab_ci.sh <file-path>
```

**Example:**
```bash
bash .claude/skills/gitlab-ci-validator/scripts/validate_gitlab_ci.sh .gitlab-ci.yml
```

This runs all three validation layers:
1. Syntax validation
2. Best practices check
3. Security scan

### Validation Options

```bash
# Run only syntax validation
bash scripts/validate_gitlab_ci.sh .gitlab-ci.yml --syntax-only

# Run only best practices check
bash scripts/validate_gitlab_ci.sh .gitlab-ci.yml --best-practices

# Run only security scan
bash scripts/validate_gitlab_ci.sh .gitlab-ci.yml --security-only

# Skip best practices check
bash scripts/validate_gitlab_ci.sh .gitlab-ci.yml --no-best-practices

# Skip security scan
bash scripts/validate_gitlab_ci.sh .gitlab-ci.yml --no-security

# Strict mode (fail on warnings)
bash scripts/validate_gitlab_ci.sh .gitlab-ci.yml --strict
```

### Individual Validators

You can also run individual validation scripts:

```bash
# Syntax validation
python3 scripts/validate_syntax.py .gitlab-ci.yml

# Best practices check
python3 scripts/check_best_practices.py .gitlab-ci.yml

# Security scan
python3 scripts/check_security.py .gitlab-ci.yml
```

## Output Example

```
════════════════════════════════════════════════════════════════════════════════
  GitLab CI/CD Validator
════════════════════════════════════════════════════════════════════════════════

File: .gitlab-ci.yml

[1/3] Running syntax validation...

✓ Syntax validation passed

[2/3] Running best practices check...

SUGGESTIONS (2):
──────────────────────────────────────────────────────────────────────────────
  SUGGESTION: Line 15: Job 'build_app' installs dependencies but doesn't use cache [cache-missing]
  💡 Suggestion: Add 'cache' configuration to speed up dependency installation

  SUGGESTION: Line 42: Job 'deploy_production' should use resource_group [missing-resource-group]
  💡 Suggestion: Add 'resource_group' to prevent concurrent deployments

⚠  Best practices check found issues

[3/3] Running security scan...

MEDIUM SEVERITY (1):
──────────────────────────────────────────────────────────────────────────────
  MEDIUM: Line 8: Using ':latest' tag in job 'test_job' is a security risk [image-latest-tag]
  🔒 Remediation: Pin to specific version or SHA digest

✓ Security scan passed

════════════════════════════════════════════════════════════════════════════════
  Validation Summary
════════════════════════════════════════════════════════════════════════════════

Syntax Validation:      PASSED
Best Practices:         WARNINGS
Security Scan:          PASSED

════════════════════════════════════════════════════════════════════════════════

✓ All validation checks passed
```

## Common Validation Scenarios

### Scenario 1: Validating a New Pipeline

```bash
# Validate syntax and structure
bash scripts/validate_gitlab_ci.sh new-pipeline.gitlab-ci.yml
```

### Scenario 2: Security Audit Before Merge

```bash
# Run security scan only with strict mode
bash scripts/validate_gitlab_ci.sh .gitlab-ci.yml --security-only --strict
```

### Scenario 3: Pipeline Optimization

```bash
# Check for best practices and optimization opportunities
bash scripts/validate_gitlab_ci.sh .gitlab-ci.yml --best-practices
```

### Scenario 4: CI/CD Integration

```bash
# In your CI/CD pipeline
stages:
  - validate

validate_pipeline:
  stage: validate
  script:
    - pip3 install PyYAML
    - bash .claude/skills/gitlab-ci-validator/scripts/validate_gitlab_ci.sh .gitlab-ci.yml --strict
```

## Integration with Claude Code

When Claude Code invokes this skill, it will:

1. **Automatically detect** `.gitlab-ci.yml` files in the project
2. **Run validation** when you ask to validate, check, or review GitLab CI/CD configurations
3. **Provide actionable feedback** with line numbers and suggestions
4. **Fetch additional documentation** from Context7 or web sources when needed for custom GitLab features

**Example prompts:**
- "Validate my GitLab CI pipeline"
- "Check this .gitlab-ci.yml for security issues"
- "Review my pipeline configuration for best practices"
- "Why is my GitLab pipeline failing?"
- "Optimize my GitLab CI/CD configuration"

## Validation Rules

### Syntax Rules
- `yaml-syntax`: Valid YAML formatting
- `job-reserved-keyword`: Job names cannot use reserved keywords
- `job-missing-script`: Jobs must have script, trigger, or extends
- `job-stage-undefined`: Referenced stages must be defined
- `dependencies-undefined-job`: Referenced jobs must exist
- `rules-not-list`: Rules must be a list
- `cache-invalid-policy`: Cache policy must be pull, push, or pull-push

### Best Practice Rules
- `cache-missing`: Dependency installation jobs should use cache
- `artifact-no-expiration`: Artifacts should have expiration
- `deprecated-only-except`: Use 'rules' instead of 'only'/'except'
- `missing-interruptible`: Test jobs should be interruptible
- `missing-retry`: Potentially flaky jobs should have retry
- `image-latest-tag`: Pin Docker images to specific versions
- `dag-optimization`: Use 'needs' for faster pipeline execution
- `parallel-opportunity`: Tests could benefit from parallelization

### Security Rules
- `hardcoded-password`: Hardcoded passwords detected
- `hardcoded-api-key`: Hardcoded API keys detected
- `secret-in-logs`: Secrets may be exposed in logs
- `curl-pipe-bash`: Dangerous curl | bash pattern
- `image-latest-tag`: Using :latest is a security risk
- `include-remote-unverified`: Remote includes without verification
- `variable-hardcoded-secret`: Sensitive variables with hardcoded values
- `artifact-broad-path`: Overly broad artifact paths

## Requirements

- **Python 3.7+**
- **PyYAML**: Install with `pip3 install PyYAML`
- **Bash**: For running the orchestrator script

Install dependencies:
```bash
pip3 install PyYAML
```

## Documentation

Comprehensive documentation is included in the `docs/` directory:

- **`gitlab-ci-reference.md`**: Complete GitLab CI/CD YAML syntax reference
- **`best-practices.md`**: Detailed best practices guide
- **`common-issues.md`**: Common issues and solutions

## Examples

Example GitLab CI/CD configurations are provided in the `examples/` directory:

- **`basic-pipeline.gitlab-ci.yml`**: Simple three-stage pipeline
- **`docker-build.gitlab-ci.yml`**: Docker build and push workflow
- **`multi-stage.gitlab-ci.yml`**: Multi-stage pipeline with DAG
- **`complex-workflow.gitlab-ci.yml`**: Advanced workflow with all features
- **`component-pipeline.gitlab-ci.yml`**: **NEW** - GitLab 17.0+ pipeline using CI/CD components from the Catalog

Test the skill with examples:
```bash
bash scripts/validate_gitlab_ci.sh examples/basic-pipeline.gitlab-ci.yml

# Test component validation (GitLab 17.0+)
bash scripts/validate_gitlab_ci.sh examples/component-pipeline.gitlab-ci.yml
```

## Fetching Latest Documentation

When encountering custom GitLab features, modules, or specific version requirements, the skill can:

1. **Use Context7 MCP** to fetch version-aware GitLab documentation
2. **Use WebSearch** to find latest GitLab CI/CD documentation
3. **Use WebFetch** to retrieve specific documentation pages from docs.gitlab.com

This ensures validation rules stay current with the latest GitLab CI/CD features.

## Extending the Skill

### Adding Custom Validation Rules

Add custom rules to the validation scripts:

1. **Syntax rules**: Edit `scripts/validate_syntax.py`
2. **Best practice rules**: Edit `scripts/check_best_practices.py`
3. **Security rules**: Edit `scripts/check_security.py`

### Custom Rule Example

```python
# In check_best_practices.py
def _check_custom_rule(self):
    """Check for custom organization rule"""
    for job_name, job in self.config.items():
        if not self._is_job(job_name):
            continue

        # Your custom validation logic
        if 'tags' not in job:
            self.issues.append(BestPracticeIssue(
                'warning',
                self._get_line(job_name),
                f"Job '{job_name}' should specify runner tags",
                'custom-missing-tags',
                "Add 'tags' to select appropriate runners"
            ))
```

## Troubleshooting

### Python Module Not Found

```bash
# Install PyYAML
pip3 install PyYAML

# Or with homebrew Python
python3 -m pip install PyYAML
```

### Permission Denied

```bash
# Make scripts executable
chmod +x scripts/*.sh scripts/*.py
```

### Validation Errors

Check the documentation:
- Review `docs/gitlab-ci-reference.md` for syntax reference
- Check `docs/common-issues.md` for known issues
- Consult `docs/best-practices.md` for recommended patterns

## Version History

### v1.1.0 (2025-01-27)
- **NEW:** Complete include validation for all types (component, project, remote, local, template)
- **NEW:** CI/CD Component validation (GitLab 17.0+)
  - Component name format validation (org/project@version)
  - Version format validation (@1.0.0, @~latest, semantic versioning)
  - Component inputs structure validation
  - Component limit validation (max 100 per project)
- **NEW:** Enhanced security checks for all include types
  - Component security (version pinning, trusted sources, hardcoded inputs)
  - Remote include integrity and HTTP/HTTPS validation
  - Project include ref pinning and branch detection
  - Local include path traversal detection
  - Template deprecation warnings
- **NEW:** gitlab-ci-local integration for local pipeline testing
  - install_tools.sh script for tool installation
  - --test-only mode in validate_gitlab_ci.sh
- **NEW:** Core Validation Workflow documentation
- **NEW:** component-pipeline.gitlab-ci.yml example
- Enhanced validation rules: 40+ validation rules (was 25)
- Improved error messages with detailed remediation steps

### v1.0.0 (2025-01-18)
- Initial release
- Syntax validation with comprehensive GitLab CI schema checking
- Best practices validation with 15+ rules
- Security scanning with 25+ security checks
- Comprehensive documentation
- Example pipeline configurations
- Integration with Context7 for latest GitLab docs

## Contributing

To improve this skill:

1. Add new validation rules to appropriate scripts
2. Update documentation with new patterns
3. Add example configurations
4. Test with real-world GitLab CI/CD files

## License

This skill is part of the DevOps Skills collection.

## Support

For issues, questions, or contributions:
- Check documentation in `docs/` directory
- Review examples in `examples/` directory
- Consult GitLab CI/CD documentation: https://docs.gitlab.com/ci/

---

**Remember**: This skill validates GitLab CI/CD configurations but does not execute pipelines. Use GitLab's CI Lint tool or `gitlab-ci-local` for testing actual pipeline execution.

Overview

This skill is a comprehensive toolkit for validating, linting, testing, and securing GitLab CI/CD pipeline configurations (.gitlab-ci.yml). It catches YAML and schema errors, highlights best-practice improvements, and performs security scans to detect hardcoded secrets, unsafe scripts, and insecure includes. Use it to enforce consistent pipeline quality and reduce CI runtime failures and security risks.

How this skill works

The validator runs a staged workflow: syntax/schema checks, best-practices analysis, and a security audit. It examines job definitions, stages, includes (component, project, remote, local, template), DAG/needs usage, cache/artifact settings, and variable handling. Outputs include line-level findings, remediation suggestions, severity levels, and optional local pipeline simulation using gitlab-ci-local for runtime validation.

When to use it

  • Validating new or changed .gitlab-ci.yml files before merge
  • Debugging pipeline failures caused by syntax, missing stages, or undefined jobs
  • Enforcing CI/CD best practices during code review or CI validation jobs
  • Performing security audits to find hardcoded secrets, unsafe scripts, or unpinned includes
  • Optimizing pipelines for performance (caching, DAG, parallelization)

Best practices

  • Pin Docker images to versions or digests instead of :latest
  • Use cache for dependency installation and set artifact expiration
  • Prefer rules over deprecated only/except and use needs for DAG optimization
  • Configure timeouts, retries, and interruptible where appropriate
  • Use resource_group for serialized deployments and avoid overly broad artifact paths

Example use cases

  • CI pipeline job that validates .gitlab-ci.yml in a pre-merge validate stage
  • Security scan pre-merge to block commits with hardcoded credentials or unsafe curl | bash patterns
  • Refactoring a monorepo pipeline: identify DAG and parallelization opportunities
  • Local testing of complex pipeline flows using gitlab-ci-local before pushing changes
  • Automated enforcement: run validator in CI with --strict to fail on warnings

FAQ

Can this detect hardcoded secrets in variables?

Yes. The security scanner flags hardcoded passwords, API keys, and sensitive variables and warns about secrets exposed to logs.

Does it validate remote and component includes?

Yes. It validates all include types (component, project, remote, local, template) and checks component format and version pinning.

Can I run only specific checks?

Yes. You can run syntax-only, best-practices-only, or security-only modes, or combine them. Strict mode makes warnings fail the check.