Skills DirectorySkills Directory
SkillsLearnSecurityCategoriesDocsBlogPro
Sign InSubmit Skill
Skills Directory

Security-tested agent skills for Claude, coding agents, and AI workflows.

Directory

  • Browse Skills
  • All Skills A–Z
  • Claude Skills
  • Claude Code Skills
  • Agent Skills
  • Categories
  • Authors
  • Submit a Skill

Learn

  • Learn Hub
  • Install Claude Skills
  • Write SKILL.md
  • Skills vs MCP
  • Directories Compared

Security

  • Security
  • Methodology
  • Secure Claude Skills
  • Security Badges
  • Chrome Extension
  • Skill Manager

Company

  • About
  • Community
  • Blog
  • API Docs
  • Advertise

2026 Skills Directory. All rights reserved.

ProTermsPrivacyRefunds
Back to skills

Cicd Gitlab Components Dev

ASecurity

Develop reusable GitLab CI/CD components and templates. Use when creating CI/CD component libraries, building include templates, packaging components for the CI/CD Catalog, or designing organization-wide pipeline templates.

8 stars
0 votes
0 copies
0 views
Added 2/8/2026
documentationgobashnodenodejsdockertestingdebugginggitci/cdsecurity

Security Analysis

A96/100
mediumInstalls packages at runtime which could introduce malicious dependencies

Pro shows the line behind each finding and how to fix it

Scanned 2/12/2026

$npx -y skills add aRustyDev/ai --skill cicd-gitlab-components-dev --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Cicd Gitlab Components Dev?

Add the live security badge to your README — it updates automatically with every re-scan.

Security grade badge for Cicd Gitlab Components Dev
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/arustydev-cicd-gitlab-components-dev/badge)](https://www.skillsdirectory.com/skills/arustydev-cicd-gitlab-components-dev)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
Files
SKILL.md
---
name: cicd-gitlab-components-dev
description: Develop reusable GitLab CI/CD components and templates. Use when creating CI/CD component libraries, building include templates, packaging components for the CI/CD Catalog, or designing organization-wide pipeline templates.
---

# GitLab CI/CD Components Development

Guide for developing reusable GitLab CI/CD components and templates that can be shared across projects and organizations.

## When to Use This Skill

- Creating reusable CI/CD component libraries
- Building include templates for shared pipelines
- Publishing to the GitLab CI/CD Catalog
- Designing organization-wide pipeline standards
- Packaging job templates and configurations
- Understanding component inputs, outputs, and specs

## Component Types

### CI/CD Components (Catalog)

Modern, versioned components with defined interfaces:

```yaml
# templates/build/template.yml
spec:
  inputs:
    stage:
      default: build
    image:
      default: node:20
    script:
      type: array

---
build-job:
  stage: $[[ inputs.stage ]]
  image: $[[ inputs.image ]]
  script: $[[ inputs.script ]]
  artifacts:
    paths:
      - dist/
```

### Include Templates

Traditional YAML templates for sharing:

```yaml
# templates/nodejs.yml
.nodejs-base:
  image: node:20
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/

.nodejs-test:
  extends: .nodejs-base
  script:
    - npm ci
    - npm test
```

## Component Structure

### Directory Layout

```
my-component/
├── templates/
│   ├── build/
│   │   └── template.yml     # Component definition
│   ├── test/
│   │   └── template.yml
│   └── deploy/
│       └── template.yml
├── README.md
└── .gitlab-ci.yml           # Tests for the components
```

### Component Specification

```yaml
# templates/my-job/template.yml
spec:
  inputs:
    # String input with default
    environment:
      description: 'Target environment'
      default: 'development'

    # Required string input
    app-name:
      description: 'Application name'

    # Boolean input
    run-tests:
      description: 'Whether to run tests'
      type: boolean
      default: true

    # Number input
    replicas:
      description: 'Number of replicas'
      type: number
      default: 1

    # Array input
    extra-args:
      description: 'Additional arguments'
      type: array
      default: []

---
# Component implementation
deploy-$[[ inputs.environment ]]:
  stage: deploy
  script:
    - echo "Deploying $[[ inputs.app-name ]] to $[[ inputs.environment ]]"
    - kubectl scale deployment/$[[ inputs.app-name ]] --replicas=$[[ inputs.replicas ]]
  rules:
    - if: $[[ inputs.run-tests ]]
      when: on_success
```

## Input Types

### String (Default)

```yaml
spec:
  inputs:
    version:
      description: 'Version to deploy'
      default: 'latest'
      options:              # Restrict to specific values
        - 'latest'
        - 'stable'
        - 'edge'
```

### Boolean

```yaml
spec:
  inputs:
    enable-cache:
      type: boolean
      default: true

---
job:
  cache:
    - if: $[[ inputs.enable-cache ]]
      paths:
        - node_modules/
```

### Number

```yaml
spec:
  inputs:
    timeout-minutes:
      type: number
      default: 30

---
job:
  timeout: $[[ inputs.timeout-minutes ]] minutes
```

### Array

```yaml
spec:
  inputs:
    services:
      type: array
      default:
        - postgres:15
        - redis:7

---
job:
  services: $[[ inputs.services ]]
```

## Using Components

### From CI/CD Catalog

```yaml
include:
  - component: gitlab.com/my-org/components/build@1.0.0
    inputs:
      image: node:20
      script:
        - npm run build
```

### From Project Repository

```yaml
include:
  - component: $CI_SERVER_HOST/$CI_PROJECT_PATH/templates/build@$CI_COMMIT_SHA
    inputs:
      stage: build
```

### Multiple Components

```yaml
include:
  - component: gitlab.com/org/components/lint@1.0
    inputs:
      config: .eslintrc.json

  - component: gitlab.com/org/components/test@1.0
    inputs:
      coverage: true

  - component: gitlab.com/org/components/deploy@1.0
    inputs:
      environment: production
```

## Template Patterns

### Hidden Jobs (Extends)

```yaml
# templates/base.yml
.base-job:
  image: alpine:latest
  before_script:
    - apk add --no-cache curl
  tags:
    - docker

.test-base:
  extends: .base-job
  stage: test
  coverage: '/Coverage: \d+\.\d+%/'

.deploy-base:
  extends: .base-job
  stage: deploy
  when: manual
```

### Parameterized Templates

```yaml
# templates/docker-build.yml
spec:
  inputs:
    dockerfile:
      default: Dockerfile
    context:
      default: '.'
    registry:
      default: $CI_REGISTRY
    image-name:
      default: $CI_PROJECT_PATH

---
docker-build:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $[[ inputs.registry ]]
    - docker build -f $[[ inputs.dockerfile ]] -t $[[ inputs.registry ]]/$[[ inputs.image-name ]]:$CI_COMMIT_SHA $[[ inputs.context ]]
    - docker push $[[ inputs.registry ]]/$[[ inputs.image-name ]]:$CI_COMMIT_SHA
```

### Job Generator Pattern

```yaml
spec:
  inputs:
    environments:
      type: array
      default:
        - staging
        - production

---
# Generates multiple jobs from array
.deploy-template:
  stage: deploy
  script:
    - ./deploy.sh $ENVIRONMENT

deploy-staging:
  extends: .deploy-template
  variables:
    ENVIRONMENT: staging
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

deploy-production:
  extends: .deploy-template
  variables:
    ENVIRONMENT: production
  when: manual
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
```

## CI/CD Catalog Publishing

### Project Configuration

```yaml
# .gitlab-ci.yml in component project
stages:
  - test
  - release

test-components:
  stage: test
  script:
    - gitlab-ci-local --list  # Validate components

create-release:
  stage: release
  script:
    - echo "Creating release"
  release:
    tag_name: $CI_COMMIT_TAG
    description: 'Release $CI_COMMIT_TAG'
  rules:
    - if: $CI_COMMIT_TAG
```

### Catalog Metadata

```yaml
# In project settings or .gitlab/ci-component.yml
---
name: My CI/CD Components
description: Reusable components for CI/CD
icon: 🚀
categories:
  - Build
  - Test
  - Deploy
```

### Versioning

```bash
# Semantic versioning for components
git tag -a v1.0.0 -m "Initial release"
git push origin v1.0.0
```

## Include Patterns

### Local Includes

```yaml
include:
  - local: '/templates/base.yml'
  - local: '/templates/nodejs.yml'
```

### Project Includes

```yaml
include:
  - project: 'my-group/ci-templates'
    ref: v1.0.0
    file:
      - '/templates/nodejs.yml'
      - '/templates/docker.yml'
```

### Remote Includes

```yaml
include:
  - remote: 'https://example.com/ci/templates/standard.yml'
```

### Template Includes

```yaml
include:
  - template: Security/SAST.gitlab-ci.yml
  - template: Code-Quality.gitlab-ci.yml
```

## Testing Components

### Component Validation

```yaml
# .gitlab-ci.yml
test:component-syntax:
  stage: test
  script:
    - |
      for template in templates/*/template.yml; do
        echo "Validating $template"
        yq eval '.' "$template" > /dev/null
      done
```

### Integration Testing

```yaml
test:component-integration:
  stage: test
  trigger:
    include:
      - component: $CI_SERVER_FQDN/$CI_PROJECT_PATH/templates/build@$CI_COMMIT_SHA
        inputs:
          script:
            - echo "Test passed"
```

### Local Testing

```bash
# Install gitlab-ci-local
npm install -g gitlab-ci-local

# Test pipeline with components
gitlab-ci-local --list
gitlab-ci-local test
```

## Advanced Patterns

### Conditional Component Content

```yaml
spec:
  inputs:
    enable-sast:
      type: boolean
      default: false

---
build:
  stage: build
  script:
    - npm run build

# Only included when enable-sast is true
sast-scan:
  rules:
    - if: $[[ inputs.enable-sast ]]
  stage: test
  script:
    - npm audit
```

### Composition of Components

```yaml
# meta-component that combines others
spec:
  inputs:
    nodejs-version:
      default: '20'
    run-security:
      type: boolean
      default: true

---
include:
  - component: gitlab.com/org/components/nodejs-setup@1.0
    inputs:
      version: $[[ inputs.nodejs-version ]]

  - component: gitlab.com/org/components/security-scan@1.0
    rules:
      - if: $[[ inputs.run-security ]]
```

### Dynamic Child Pipelines

```yaml
spec:
  inputs:
    services:
      type: array

---
generate-pipeline:
  stage: build
  script:
    - |
      cat > child-pipeline.yml << EOF
      stages:
        - deploy
      EOF
      for service in $[[ inputs.services | join(" ") ]]; do
        cat >> child-pipeline.yml << EOF
      deploy-$service:
        stage: deploy
        script:
          - ./deploy.sh $service
      EOF
      done
  artifacts:
    paths:
      - child-pipeline.yml

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

## Documentation

### Component README

```markdown
# Component Name

Brief description of what this component does.

## Usage

\`\`\`yaml
include:
  - component: gitlab.com/org/my-component@1.0.0
    inputs:
      param1: value1
\`\`\`

## Inputs

| Input | Type | Default | Description |
|-------|------|---------|-------------|
| `param1` | string | `default` | What it does |
| `enable-x` | boolean | `true` | Whether to enable X |

## Examples

### Basic Usage

\`\`\`yaml
include:
  - component: gitlab.com/org/my-component@1.0.0
\`\`\`

### Advanced Usage

\`\`\`yaml
include:
  - component: gitlab.com/org/my-component@1.0.0
    inputs:
      param1: custom-value
      enable-x: false
\`\`\`

## Outputs

This component creates the following jobs:
- `build`: Builds the application
- `test`: Runs tests
```

## Debugging Checklist

- [ ] Verify component spec syntax (inputs, types, defaults)
- [ ] Check `$[[ ]]` interpolation syntax (not `${{ }}`)
- [ ] Ensure inputs are passed correctly when including
- [ ] Validate YAML structure with linter
- [ ] Test component locally with gitlab-ci-local
- [ ] Verify version tags exist for referenced components
- [ ] Check project visibility allows component access

## References

- [GitLab CI/CD Components](https://docs.gitlab.com/ee/ci/components/)
- [CI/CD Catalog](https://docs.gitlab.com/ee/ci/components/#cicd-catalog)
- [Component Inputs](https://docs.gitlab.com/ee/ci/components/#define-inputs)
- [Include Keyword](https://docs.gitlab.com/ee/ci/yaml/#include)
- [Extends Keyword](https://docs.gitlab.com/ee/ci/yaml/#extends)
- [gitlab-ci-local](https://github.com/firecow/gitlab-ci-local)

Attribution

aRustyDevaRustyDev
View sourceSee grades on GitHubMore from aRustyDev →
SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Related Skills

Context Fundamentals

Understand the components, mechanics, and constraints of context in agent systems. Use when designing agent architectures, debugging context-related failures, or optimizing context usage.

179001 votes

Architecture Diagram Creator

Create comprehensive HTML architecture diagrams with data flows, business context, and system architecture.

6661 votes

release-notes

Draft release notes and changelog entries from git history or merged PRs between two refs (tags/SHAs/branches), including breaking changes, migrations, and upgrade steps. Use when the user asks for release notes, changelog updates, or a GitHub Release draft.

1301 votes

docs-style-guide

Documentation style guide enforcer by @planetabhi. Applies and reviews the writing style guide when authoring or editing product documentation and tutorials. Use to check prose for voice, tense, word choice, inclusive language, formatting, code block, UI, Markdown, and number/date conventions.

11 votes

Docx

Use this skill whenever the user wants to create, read, edit, or manipulate Word documents (.docx files) or Word templates (.dotx files). Triggers include: any mention of 'Word doc', 'word document', '.docx', '.dotx', or requests to produce professional documents with formatting like tables of contents, headings, page numbers, or letterheads. Also use when extracting or reorganizing content from .docx or .dotx files, inserting or replacing images in documents, performing find-and-replace in W...

1798860 votes
View all in documentation →