gitlab-ci-patterns
Install this skill
npx skills add wshobson/agentsWorks 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
- Define stages for build, test, and production deployment in YAML
- Configure cache paths for project dependencies to speed up runners
- Create a Docker build job using DinD services
- Add a manual step with an environment definition for production
- 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
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.
📄 Full skill instructions — original source: wshobson/agents
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 handlingHow to Use This Skill Unit
Option A: Project-Specific (Recommended)
- Click "Download" above
- In your project, create the directory:
.agent/skills/gitlab-ci-patterns/ - Save the file as
SKILL.md - 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