Back to DevOps & CI/CD

gitlab-ci-patterns

GitLab CICI/CDDevOpsPipelinesAutomationKubernetesCachingDeployment
36.8k📄 MIT🕒 2026-06-16Source ↗

Install this skill

npx skills add wshobson/agents

Works across Claude Code, Cursor, Codex, Copilot & Antigravity

The gitlab-ci-patterns skill provides a structured library of YAML configurations for GitLab CI/CD workflows. It standardizes common DevOps tasks including automated dependency caching, Docker image registry interaction, multi-environment deployment, and infrastructure-as-code management via Terraform. By implementing these patterns, developers avoid repetitive configuration errors when building pipelines for Node.js projects, Kubernetes clusters, or security scanning. The skill focuses on efficient stage organization, artifact management between pipeline jobs, and the use of triggers for dynamic child pipelines. This resource is intended for developers and DevOps engineers aiming to maintain high-quality pipeline consistency across multiple repositories without reinventing configuration logic for standard CI/CD operations.

When to Use This Skill

  • Automating multi-stage deployment pipelines for Kubernetes
  • Implementing persistent dependency caching for Node.js projects
  • Orchestrating Terraform infrastructure plans and applications
  • Enforcing security scans across container image registries

How to Invoke This Skill

Example prompts that trigger this skill in Claude Code, Cursor, or Antigravity:

  • Create a GitLab CI pipeline for my Node.js application
  • How do I set up a manual deployment gate in GitLab?
  • Show me a pattern for Terraform in GitLab CI
  • Add Docker build and push to my .gitlab-ci.yml
  • How can I use child pipelines in GitLab CI?

Pro Tips

  • 💡Leverage `include` statements for reusable job templates and complex pipeline compositions, promoting DRY principles across your projects.
  • 💡Strategically combine `cache` and `artifacts` to minimize build times; use cache for dependencies (`node_modules`) and artifacts for build outputs passed between stages (e.g., `dist/`).
  • 💡Monitor pipeline analytics in GitLab to identify bottlenecks and optimize resource allocation for your runners, especially in distributed setups, to maximize efficiency.

What this skill does

  • Standardized YAML templates for build, test, and deploy stages
  • Docker-in-Docker configuration for image registry pushes
  • Granular cache policies for dependency management
  • Manual gates and environment tracking for production releases
  • Integration of SAST and dependency security scanning templates
  • Dynamic child pipeline generation via artifact triggers

When not to use it

  • Projects requiring heavy GUI-based CI configuration
  • Environments relying on non-GitLab CI runners or platforms

Example workflow

  1. Define stages for build, test, and production deployment in YAML
  2. Configure cache paths for project dependencies to speed up runners
  3. Create a Docker build job using DinD services
  4. Add a manual step with an environment definition for production
  5. Include security scanning templates to validate container integrity

Prerequisites

  • Active GitLab account
  • GitLab Runner registered to the project
  • Access to a container registry

Pitfalls & limitations

  • !Over-caching can lead to stale dependencies if keys are not unique
  • !Using 'latest' image tags creates non-reproducible pipeline behavior
  • !Hardcoding secrets in YAML instead of using GitLab CI variables

FAQ

Why should I use cache instead of artifacts?
Cache is for reusing dependencies like node_modules to speed up builds, while artifacts pass build outputs like dist folders between different stages.
Can I use these patterns with non-Kubernetes deployments?
Yes, although many examples focus on Kubernetes, the pipeline stage structures and caching patterns are platform-agnostic.
What is the best way to handle sensitive credentials?
Always store tokens, URLs, and registry credentials as protected CI/CD variables in the GitLab project settings instead of committing them to the YAML file.
How do I prevent production deployments from running automatically?
Include the 'when: manual' directive in your deployment job to require a user to click a button in the GitLab UI before execution.

How it compares

Generic prompts often result in broken, outdated YAML syntax; this skill provides tested, consistent patterns that follow GitLab best practices for performance and security.

Source & trust

37k stars📄 MIT🕒 Updated 2026-06-16
📄 Full skill instructions — original source: wshobson/agents
# GitLab CI Patterns

Comprehensive GitLab CI/CD pipeline patterns for automated testing, building, and deployment.

## Purpose

Create efficient GitLab CI pipelines with proper stage organization, caching, and deployment strategies.

## When to Use

- Automate GitLab-based CI/CD
- Implement multi-stage pipelines
- Configure GitLab Runners
- Deploy to Kubernetes from GitLab
- Implement GitOps workflows

## Basic Pipeline Structure

stages:
- build
- test
- deploy

variables:
DOCKER_DRIVER: overlay2
DOCKER_TLS_CERTDIR: "/certs"

build:
stage: build
image: node:20
script:
- npm ci
- npm run build
artifacts:
paths:
- dist/
expire_in: 1 hour
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- node_modules/

test:
stage: test
image: node:20
script:
- npm ci
- npm run lint
- npm test
coverage: '/Lines\s*:\s*(\d+\.\d+)%/'
artifacts:
reports:
coverage_report:
coverage_format: cobertura
path: coverage/cobertura-coverage.xml

deploy:
stage: deploy
image: bitnami/kubectl:latest
script:
- kubectl apply -f k8s/
- kubectl rollout status deployment/my-app
only:
- main
environment:
name: production
url: https://app.example.com


## Docker Build and Push

build-docker:
stage: build
image: docker:24
services:
- docker:24-dind
before_script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
script:
- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
- docker build -t $CI_REGISTRY_IMAGE:latest .
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
- docker push $CI_REGISTRY_IMAGE:latest
only:
- main
- tags


## Multi-Environment Deployment

.deploy_template: &deploy_template
image: bitnami/kubectl:latest
before_script:
- kubectl config set-cluster k8s --server="$KUBE_URL" --insecure-skip-tls-verify=true
- kubectl config set-credentials admin --token="$KUBE_TOKEN"
- kubectl config set-context default --cluster=k8s --user=admin
- kubectl config use-context default

deploy:staging:
<<: *deploy_template
stage: deploy
script:
- kubectl apply -f k8s/ -n staging
- kubectl rollout status deployment/my-app -n staging
environment:
name: staging
url: https://staging.example.com
only:
- develop

deploy:production:
<<: *deploy_template
stage: deploy
script:
- kubectl apply -f k8s/ -n production
- kubectl rollout status deployment/my-app -n production
environment:
name: production
url: https://app.example.com
when: manual
only:
- main


## Terraform Pipeline

stages:
- validate
- plan
- apply

variables:
TF_ROOT: ${CI_PROJECT_DIR}/terraform
TF_VERSION: "1.6.0"

before_script:
- cd ${TF_ROOT}
- terraform --version

validate:
stage: validate
image: hashicorp/terraform:${TF_VERSION}
script:
- terraform init -backend=false
- terraform validate
- terraform fmt -check

plan:
stage: plan
image: hashicorp/terraform:${TF_VERSION}
script:
- terraform init
- terraform plan -out=tfplan
artifacts:
paths:
- ${TF_ROOT}/tfplan
expire_in: 1 day

apply:
stage: apply
image: hashicorp/terraform:${TF_VERSION}
script:
- terraform init
- terraform apply -auto-approve tfplan
dependencies:
- plan
when: manual
only:
- main


## Security Scanning

include:
- template: Security/SAST.gitlab-ci.yml
- template: Security/Dependency-Scanning.gitlab-ci.yml
- template: Security/Container-Scanning.gitlab-ci.yml

trivy-scan:
stage: test
image: aquasec/trivy:latest
script:
- trivy image --exit-code 1 --severity HIGH,CRITICAL $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
allow_failure: true


## Caching Strategies

# Cache node_modules
build:
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- node_modules/
policy: pull-push

# Global cache
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- .cache/
- vendor/

# Separate cache per job
job1:
cache:
key: job1-cache
paths:
- build/

job2:
cache:
key: job2-cache
paths:
- dist/


## Dynamic Child Pipelines

generate-pipeline:
stage: build
script:
- python generate_pipeline.py > child-pipeline.yml
artifacts:
paths:
- child-pipeline.yml

trigger-child:
stage: deploy
trigger:
include:
- artifact: child-pipeline.yml
job: generate-pipeline
strategy: depend


## Reference Files

- assets/gitlab-ci.yml.template - Complete pipeline template
- references/pipeline-stages.md - Stage organization patterns

## Best Practices

1. **Use specific image tags** (node:20, not node:latest)
2. **Cache dependencies** appropriately
3. **Use artifacts** for build outputs
4. **Implement manual gates** for production
5. **Use environments** for deployment tracking
6. **Enable merge request pipelines**
7. **Use pipeline schedules** for recurring jobs
8. **Implement security scanning**
9. **Use CI/CD variables** for secrets
10. **Monitor pipeline performance**

## Related Skills

- github-actions-templates - For GitHub Actions
- deployment-pipeline-design - For architecture
- secrets-management - For secrets handling

How to Use This Skill Unit

Option A: Project-Specific (Recommended)

  1. Click "Download" above
  2. In your project, create the directory: .agent/skills/gitlab-ci-patterns/
  3. Save the file as SKILL.md
  4. The agent will automatically discover the skill based on its description.

Option B: Global Installation (All Agents)

Save the file to these locations to make it available across all projects:

  • Claude Code: ~/.claude/skills/wshobson/agents/gitlab-ci-patterns/SKILL.md
  • Cursor: ~/.cursor/skills/wshobson/agents/gitlab-ci-patterns/SKILL.md
  • Antigravity: ~/.gemini/antigravity/skills/wshobson/agents/gitlab-ci-patterns/SKILL.md

🚀 Install with CLI:
npx skills add wshobson/agents

Read the Master Guide: Mastering Agent Skills

Recommended Rules

View more rules

Recommended Workflows

View more workflows

Recommended MCP Servers

View more MCP servers

Take It Further

Maximize your productivity with these powerful resources

📋

Define Your Standards

Set up coding standards to ensure this workflow produces consistent, high-quality results.

Browse Rules Library
📖

Master Workflows

Learn how to create custom workflows, use Turbo Mode, and build your automation library.

Complete Guide

How to use this Skill in Claude Code & Cursor

For Claude Code (CLI)

To use this skill in Claude Code, copy the rule content into your project's custom instructions or follow our Add-Skill CLI guide. This ensures Claude follows your standards during every code generation.

For Cursor & Windsurf

For Cursor or Windsurf, individual skills are best used in the "Rules for AI" section. This specific unit helps the agent avoid devops & ci/cd issues, leading to cleaner, more efficient code.

Why the skill format matters: the standardized Agent Skills format lets your AI agent load detailed instructions only when they are relevant, keeping your prompt clean while improving results.

Source & attribution

This skill is categorized under DevOps & CI/CD and is published by W. Shobson, maintained in wshobson/agents.

← Browse All Agent Skills
Sponsored AI assistant. Recommendations may be paid.