Gitlab Cicd Pipeline
Stand up a GitLab `.gitlab-ci.yml` with lint, test, build, security, and review/production deploy stages for a solo repo.
Overview
GitLab CI/CD Pipeline is an agent skill for the Ship phase that designs and implements GitLab pipelines with stages, jobs, artifacts, caching, and deployment strategies.
Install
npx skills add https://github.com/aj-geddes/useful-ai-prompts --skill gitlab-cicd-pipelineWhat is this skill?
- Multi-stage pipeline pattern: lint → test → build → security → deploy-review → deploy-prod
- Cache keys on `${CI_COMMIT_REF_SLUG}` for `node_modules/` and `.npm/`
- GitLab Runner, Docker image execution, and registry integration guidance
- Reference guides for complete pipeline config and runner setup under `references/`
- Variables such as `DOCKER_DRIVER` and `FF_USE_FASTZIP` for faster container builds
- 6 pipeline stages in the quick-start example: lint, test, build, security, deploy-review, deploy-prod
Adoption & trust: 511 installs on skills.sh; 251 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have code in GitLab but no reliable automated path from commit to tested artifacts and deployed environments.
Who is it for?
Indie builders on GitLab who want review apps, Docker-based jobs, and production deploy jobs in one pipeline.
Skip if: Teams on GitHub Actions-only workflows with no GitLab Runner, or repos that only need a single local test script with no deployment.
When should I use this skill?
GitLab repository CI/CD setup, multi-stage build pipelines, Docker registry integration, Kubernetes deployment, review app deployment, cache optimization, or dependency management.
What do I get? / Deliverables
You get a structured `.gitlab-ci.yml` and runner-oriented setup aligned to lint, test, build, security, and deploy stages you can run on every push.
- .gitlab-ci.yml with staged jobs
- Runner and cache configuration notes
- Deploy/review job patterns from reference guides
Recommended Skills
Journey fit
CI/CD belongs on the Ship shelf because it automates verification and deployment after the product exists in a repo. Launch subphase is the canonical fit for pipeline jobs that ship review apps and production deploys, even though earlier stages run tests and security scans.
How it compares
Use for GitLab-native CI YAML and runner patterns instead of copying generic GitHub Actions recipes.
Common Questions / FAQ
Who is gitlab-cicd-pipeline for?
Solo and small-team developers who host code on GitLab and need automated build, test, security, and deploy pipelines on runners.
When should I use gitlab-cicd-pipeline?
Use it during Ship when setting up GitLab CI/CD, multi-stage builds, Docker registry integration, Kubernetes deploys, review apps, or cache tuning—after you have a repo ready to automate.
Is gitlab-cicd-pipeline safe to install?
Review the Security Audits panel on this Prism page before installing; pipeline skills often assume shell and registry credentials in CI variables.
SKILL.md
READMESKILL.md - Gitlab Cicd Pipeline
# GitLab CI/CD Pipeline ## Table of Contents - [Overview](#overview) - [When to Use](#when-to-use) - [Quick Start](#quick-start) - [Reference Guides](#reference-guides) - [Best Practices](#best-practices) ## Overview Create comprehensive GitLab CI/CD pipelines that automate building, testing, and deployment using GitLab Runner infrastructure and container execution. ## When to Use - GitLab repository CI/CD setup - Multi-stage build pipelines - Docker registry integration - Kubernetes deployment - Review app deployment - Cache optimization - Dependency management ## Quick Start Minimal working example: ```yaml # .gitlab-ci.yml image: node:18-alpine variables: DOCKER_DRIVER: overlay2 FF_USE_FASTZIP: "true" stages: - lint - test - build - security - deploy-review - deploy-prod cache: key: ${CI_COMMIT_REF_SLUG} paths: - node_modules/ - .npm/ lint: stage: lint script: - npm install // ... (see reference guides for full implementation) ``` ## Reference Guides Detailed implementations in the `references/` directory: | Guide | Contents | |---|---| | [Complete Pipeline Configuration](references/complete-pipeline-configuration.md) | Complete Pipeline Configuration | | [GitLab Runner Configuration](references/gitlab-runner-configuration.md) | GitLab Runner Configuration | | [Docker Layer Caching Optimization](references/docker-layer-caching-optimization.md) | Docker Layer Caching Optimization | | [Multi-Project Pipeline](references/multi-project-pipeline.md) | Multi-Project Pipeline | | [Kubernetes Deployment](references/kubernetes-deployment.md) | Kubernetes Deployment, Performance Testing Stage, Release Pipeline with Semantic Versioning | ## Best Practices ### ✅ DO - Use stages to organize pipeline flow - Implement caching for dependencies - Use artifacts for test reports - Set appropriate cache keys - Implement conditional execution with `only` and `except` - Use `needs:` for job dependencies - Clean up artifacts with `expire_in` - Use Docker for consistent environments - Implement security scanning stages - Set resource limits for jobs - Use merge request pipelines ### ❌ DON'T - Run tests serially when parallelizable - Cache everything unnecessarily - Leave large artifacts indefinitely - Store secrets in configuration files - Run privileged Docker without necessity - Skip security scanning - Ignore pipeline failures - Use `only: [main]` without proper controls # Complete Pipeline Configuration ## Complete Pipeline Configuration ```yaml # .gitlab-ci.yml image: node:18-alpine variables: DOCKER_DRIVER: overlay2 FF_USE_FASTZIP: "true" stages: - lint - test - build - security - deploy-review - deploy-prod cache: key: ${CI_COMMIT_REF_SLUG} paths: - node_modules/ - .npm/ lint: stage: lint script: - npm install - npm run lint - npm run format:check artifacts: reports: codequality: code-quality-report.json expire_in: 1 week unit-tests: stage: test script: - npm install - npm run test:coverage artifacts: reports: coverage_report: coverage_format: cobertura path: coverage/cobertura-coverage.xml junit: test-results.xml paths: - coverage/ expire_in: 1 week coverage: '/Coverage: \d+\.\d+%/' integration-tests: stage: test services: - postgres:13 - redis:7 variables: POSTGRES_DB: test_db POSTGRES_USER: test_user POSTGRES_PASSWORD: test_password script: - npm run test:integration only: - merge_requests - main build: stage: build image: docker:latest services: - docker:dind variables: DOCKER_HOST: tcp://docker:2375 REGISTRY: registry.gitlab.com script: - docker login -u $CI_REGISTRY_USER -p $CI