AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

Harness Pipeline Design

skill-dungnotnull-hybrid-harness-chaos-process-prm-s04-pipeline-design · by dungnotnull

>

No reviews yet
0 installs
29 views
0.0% view→install

Install

$ agentstack add skill-dungnotnull-hybrid-harness-chaos-process-prm-s04-pipeline-design

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets Used
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-dungnotnull-hybrid-harness-chaos-process-prm-s04-pipeline-design)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
3mo ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Harness Pipeline Design? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Harness Pipeline Design

Purpose

Produce complete, schema-valid Harness pipeline YAML that follows enterprise engineering standards: parameterized inputs, environment promotion, integrated verification, and chaos-ready stage structure.


Input Contract

| Input | Source | Required | |---|---|---| | PRD / BA analysis output | s01 (workflowcontext.prd) | Yes | | Service name, artifact source, stack info | s01 context | Yes | | Environment tier list (dev/staging/prod) | s01 context or user | Yes | | Deploy strategy preference | s02 taste (deployment category) | No (defaults to Rolling) | | Approval mechanism preference | s02 taste (risktolerance) | No | | Observability tool preference | s02 taste (observability) | No | | Harness account/project identifiers | User or CLAUDE.md | Yes |

Output Contract

| Output | Destination | Format | |---|---|---| | Pipeline YAML | .commandcode/artifacts/pipeline-.yaml | YAML | | Trigger config YAML | .commandcode/artifacts/trigger-.yaml | YAML | | Pipeline context (for s05, s12, s19) | workflow_context.artifacts | YAML object | | Input set templates per env | .commandcode/artifacts/inputset-.yaml | YAML |


Prerequisites

Before generating any pipeline, confirm:

  • [ ] Harness Account ID and Organization / Project identifiers known
  • [ ] Target deployment type: Kubernetes / ECS / Lambda / VM / Custom
  • [ ] Artifact source: Docker registry / ECR / GCR / Nexus / Artifactory
  • [ ] Environment tiers required: dev → staging → preprod → prod
  • [ ] Approval mechanism: automatic / manual / JIRA / ServiceNow
  • [ ] Observability stack: Prometheus / Datadog / New Relic / AppDynamics

If any item is unknown, surface a question to the user before generating YAML.


Pipeline Anatomy

Pipeline
├── Variables (runtime inputs, expressions)
├── Stages
│   ├── CI Stage (Build + Test + Push)
│   │   ├── Steps: Clone → Build → Unit Test → SAST → Push
│   │   └── Caching: Intelligence cache / S3 cache
│   ├── CD Stage (Deploy)
│   │   ├── Service (artifact + manifests)
│   │   ├── Environment (infrastructure definition)
│   │   ├── Execution
│   │   │   ├── Pre-deployment: secrets sync, DB migration
│   │   │   ├── Deploy step: Rolling / Canary / Blue-Green
│   │   │   ├── Chaos step (optional, see chaos/01-experiment-design)
│   │   │   └── Verify step (CV — see harness/06-cv-verification)
│   │   └── Rollback (auto on failure)
│   └── Approval Stage (between envs)
└── Notification Rules (Slack / email / PagerDuty)

Workflow

Step 1 — Gather Parameters

Collect via conversation or structured input:

service_name:       # e.g., payment-service
artifact_image:     # e.g., gcr.io/myproject/payment-service
environments:       # [dev, staging, prod]
deploy_strategy:    # rolling | canary | blueGreen
k8s_namespace:      # e.g., payments
approval_type:      # none | manual | jira
chaos_enabled:      # true | false
cv_enabled:         # true | false

Step 2 — Scaffold Pipeline YAML

Generate from the canonical template below. Replace `` tokens.

Step 3 — Validate

Run mental schema check:

  • All identifier fields: [a-zA-Z_][a-zA-Z0-9_]* (no hyphens)
  • All name fields: human-readable, spaces allowed
  • No hardcoded secrets (use `` expressions)
  • Expression syntax: `, , `

Step 4 — Output

Return complete YAML with inline comments explaining non-obvious fields.


Canonical Pipeline Template

# Generated by: hybrid-harness-chaos-process-prm
pipeline:
  name: -pipeline
  identifier: _pipeline
  projectIdentifier: 
  orgIdentifier: 
  description: "CI/CD pipeline for "
  tags:
    managed-by: hcprm
    service: 

  variables:
    - name: imageTag
      type: String
      description: "Docker image tag to deploy"
      required: true
      value: 
    - name: targetEnv
      type: String
      description: "Target environment"
      required: true
      value: .allowedValues(dev,staging,preprod,prod)

  stages:
    # ─────────────────────────────────────────────
    # Stage 1: CI — Build and Push
    # ─────────────────────────────────────────────
    - stage:
        name: Build
        identifier: Build
        type: CI
        spec:
          cloneCodebase: true
          caching:
            enabled: true
            paths:
              - node_modules
              - .gradle/caches
          execution:
            steps:
              - step:
                  name: Run Unit Tests
                  identifier: run_unit_tests
                  type: Run
                  spec:
                    connectorRef: account.dockerhub
                    image: node:20-alpine
                    command: |
                      npm ci
                      npm test -- --coverage
                    reports:
                      type: JUnit
                      spec:
                        paths:
                          - "**/junit.xml"
              - step:
                  name: Build and Push Image
                  identifier: build_push_image
                  type: BuildAndPushDockerRegistry
                  spec:
                    connectorRef: account.dockerhub
                    repo: /
                    tags:
                      - 
                      - latest

    # ─────────────────────────────────────────────
    # Stage 2: Deploy to Environment
    # ─────────────────────────────────────────────
    - stage:
        name: Deploy 
        identifier: Deploy_
        type: Deployment
        spec:
          deploymentType: Kubernetes
          service:
            serviceRef: _svc
            serviceInputs:
              serviceDefinition:
                type: Kubernetes
                spec:
                  artifacts:
                    primary:
                      primaryArtifactRef: primary
                      sources:
                        - identifier: primary
                          spec:
                            tag: 
          environment:
            environmentRef: 
            deployToAll: false
            infrastructureDefinitions:
              - identifier: 
          execution:
            steps:
              - stepGroup:
                  name: Pre-Deployment
                  identifier: pre_deployment
                  steps:
                    - step:
                        name: Sync Secrets
                        identifier: sync_secrets
                        type: ShellScript
                        spec:
                          shell: Bash
                          source:
                            type: Inline
                            spec:
                              script: |
                                echo "Syncing secrets for "
                                # Add secret sync logic here
                          onDelegate: true
              - step:
                  name: Rolling Deploy
                  identifier: rolling_deploy
                  type: K8sRollingDeploy
                  spec:
                    skipDryRun: false
                    pruningEnabled: true
              # ── Chaos Step (inject after deploy, before verify) ──
              # See chaos/01-experiment-design for full config
              # - step:
              #     name: Chaos Experiment
              #     identifier: chaos_experiment
              #     type: Chaos
              #     spec:
              #       experimentRef: 
              #       expectedResilienceScore: 80
              #
              # ── Continuous Verification ──
              # See harness/06-cv-verification for full config
              # - step:
              #     name: Verify Deployment
              #     identifier: verify_deployment
              #     type: Verify
              #     spec:
              #       isMultiServicesOrEnvs: false
              #       type: Canary
              #       monitoredServiceRef: 
              #       healthSources: []
              #       duration: 10m
            rollbackSteps:
              - step:
                  name: Rollback Deployment
                  identifier: rollback_deployment
                  type: K8sRollingRollback
                  spec: {}

    # ─────────────────────────────────────────────
    # Stage 3: Approval Gate (between envs)
    # ─────────────────────────────────────────────
    - stage:
        name: Approve Production
        identifier: Approve_Production
        type: Approval
        spec:
          execution:
            steps:
              - step:
                  name: Production Approval
                  identifier: production_approval
                  type: HarnessApproval
                  spec:
                    approvalMessage: |
                      Approve deployment of 
                      to production environment?
                    includePipelineExecutionHistory: true
                    approvers:
                      minimumCount: 2
                      disallowPipelineExecutor: true
                      userGroups:
                        - account.SRE_Team
                        - account.Engineering_Leads
                    approverInputs:
                      - name: releaseNotes
                        defaultValue: ""
                    autoApproval:
                      action: REJECT
                      scheduledDeadline:
                        timeZone: UTC
                        time: "23:59"
        when:
          pipelineStatus: Success
          condition:  == "prod"

Deploy Strategy Variants

Read references/deploy-strategies.md for full Canary and Blue-Green templates.

Quick reference:

| Strategy | Use When | Rollback Speed | |---|---|---| | Rolling | Low risk, stateless services | Medium (re-deploy old) | | Canary | Need traffic split validation | Fast (route 0% to canary) | | BlueGreen | Zero-downtime, instant cutover | Instant (swap service selector) |


Trigger Configuration

# Webhook trigger for main branch push
trigger:
  name: On Main Push
  identifier: on_main_push
  type: Webhook
  spec:
    type: Github
    spec:
      type: Push
      spec:
        connectorRef: account.github_connector
        repoName: /
        autoAbortPreviousExecutions: true
        payloadConditions:
          - key: targetBranch
            operator: Equals
            value: main
      headerConditions: []
  inputYaml: |
    pipeline:
      identifier: _pipeline
      variables:
        - name: imageTag
          value: 

Expression Cheat Sheet

| Expression | Resolves To | |---|---| | ` | Full image URI | | | Image tag | | | Environment name | | | PreProduction / Production | | | Kubernetes namespace | | | Current execution UUID | | | Git commit SHA (webhook) | | | Secret value (never logs) | | ` | Cross-stage output |


AI Agent Integration

Autonomy Level

| Aspect | Level | Description | |---|---|---| | Current | L2 | AI generates pipeline YAML from natural language | | Target | L3 | AI generates and validates pipelines, human reviews |

Harness AI Agent

Agent: Harness AI DevOps Agent (Claude Opus 4.5 via Vertex AI) Capabilities:

  • Natural language pipeline YAML generation across all modules
  • Error Analyzer (change impact + dependency checks + historical patterns + RCA + fix recommendations)
  • Pipeline Summarizer
  • Multi-stage pipeline creation validated with 50-stage pipelines

Human Gates

  • Pipeline approval before first deployment
  • Security-sensitive stage configuration
  • Production environment pipeline changes

Fallback

When Harness AI is unavailable: Use static pipeline templates from s09 Template Library and manual YAML construction following Harness schema documentation.


Success Criteria

  • [ ] Pipeline YAML passes harness pipeline lint (or manual schema review)
  • [ ] No hardcoded credentials
  • [ ] All stages have rollback steps
  • [ ] At minimum one health check or CV step before marking success
  • [ ] Trigger configured and tested

Common Pitfalls

  • Identifier contains hyphen → Harness will reject; use underscore
  • Missing when conditions → stages run unconditionally, including approval in dev
  • Hardcoded image tags → use `` instead
  • No pruningEnabled → stale Kubernetes resources accumulate over time

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.