
Gitlab Ci Patterns
Stand up GitLab CI/CD with staged build, test, and deploy jobs, caching, artifacts, and runner-friendly images for solo repos shipping to Kubernetes or similar.
Overview
gitlab-ci-patterns is an agent skill most often used in Ship (also Build integrations) that supplies GitLab CI/CD YAML patterns for multi-stage build, test, cache, and deploy automation.
Install
npx skills add https://github.com/wshobson/agents --skill gitlab-ci-patternsWhat is this skill?
- Reference pipeline with build → test → deploy stages, shared variables, and per-job Docker images
- Artifacts and cache patterns keyed by branch slug for node_modules and dist output
- Test stage with lint, unit tests, and Cobertura coverage report extraction via regex
- Deploy job example using kubectl apply and rollout status restricted to main with named environment
- Covers runner configuration, Kubernetes deploy from GitLab, and GitOps-oriented workflows per skill intent
- Example pipeline defines 3 stages: build, test, deploy
- Sample test job parses coverage with a Lines percentage regex for GitLab reports
Adoption & trust: 8.4k installs on skills.sh; 36.5k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your GitLab repo lacks a dependable pipeline, so every push risks manual builds, skipped tests, or ad-hoc deploys.
Who is it for?
Indie developers on GitLab who want kubectl-or-similar deploy stages and repeatable test gates before merging to main.
Skip if: Teams on GitHub Actions-only workflows, serverless-only deploys with no YAML CI interest, or orgs that forbid agents editing pipeline secrets.
When should I use this skill?
Implementing GitLab CI/CD, optimizing pipeline performance, or setting up automated testing and deployment on GitLab.
What do I get? / Deliverables
You get stage-organized pipeline templates with caching, artifacts, coverage reporting, and deployment hooks you can drop into .gitlab-ci.yml and iterate with your runners.
- .gitlab-ci.yml stage definitions with build, test, and deploy jobs
- Cache and artifact configuration snippets adaptable to your stack
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Primary shelf is Ship because the skill encodes pipelines that gate releases—build artifacts, run tests, then deploy—rather than application feature code. Launch subphase fits automated deployment stages, environments, and rollout commands that move verified builds into production.
Where it fits
Add a GitLab pipeline that builds Docker images and publishes artifacts for downstream deploy jobs.
Enforce lint and unit tests with coverage artifacts on every merge request before deploy stages run.
Extend deploy jobs with kubectl rollout checks and environment tracking for production stability.
How it compares
Opinionated GitLab .gitlab-ci.yml cookbooks—not a generic “any CI” skill or a managed GitLab product doc mirror.
Common Questions / FAQ
Who is gitlab-ci-patterns for?
Solo builders and small teams using GitLab who need agent help authoring or optimizing pipelines with runners, caches, and deploy stages.
When should I use gitlab-ci-patterns?
Use it during Ship when adding automated testing and deployment on GitLab; during Build when wiring repo integrations and containerized jobs; during Operate when extending GitOps or Kubernetes rollout steps from CI.
Is gitlab-ci-patterns safe to install?
The skill suggests pipeline YAML that may reference deploy credentials and cluster access—review the Security Audits panel on this page and restrict who can merge CI changes that touch secrets.
SKILL.md
READMESKILL.md - Gitlab Ci Patterns
# 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 ```yaml 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:1.31 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 ```yaml 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 ```yaml .deploy_template: &deploy_template image: bitnami/kubectl:1.31 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 ```yaml 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 ```yaml 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:0.58.0 script: - trivy image --exit-code 1 --sev