arn-infra-pipeline

Arness Infra Pipeline

Generate infrastructure-specific CI/CD pipelines (separate from application CI/CD) with SOC 2 alignment. This skill produces four pipeline jobs: PR validation, staging deployment, production promotion, and scheduled cleanup. It detects existing CI configurations from arn-spark and extends rather than replaces them.

The generated pipelines implement security best practices: OIDC authentication for cloud providers (no static credentials), separate IAM roles per environment, plan-as-artifact audit trails, and branch protection enforcement.

Prerequisites

Read ## Arness from the project's CLAUDE.md. If no ## Arness section exists or Arness Infra fields are missing, inform the user: "Arness Infra is not configured for this project yet. Run /arn-infra-wizard to get started — it will set everything up automatically." Do not proceed without it.

Check the Deferred field. If Deferred: yes, inform the user: "Infrastructure is in deferred mode. CI/CD pipeline setup is not available until infrastructure is fully configured. Run /arn-infra-assess to un-defer." Stop.

Extract:

• Experience level -- derived from user profile. Read ~/.arness/user-profile.yaml (or .claude/arness-profile.local.md if it exists — project override takes precedence). Apply the experience derivation mapping from ${CLAUDE_PLUGIN_ROOT}/skills/arn-infra-ensure-config/references/experience-derivation.md. If no profile exists, check for legacy Experience level in ## Arness as fallback.
• Platform -- code hosting platform (github, bitbucket, none)
• Providers -- cloud providers in use
• Providers config -- path to providers.md for per-provider IaC tool details
• Default IaC tool -- the default IaC tool
• Environments -- environment names in promotion order
• Environments config -- path to environments.md for promotion rules
• Tooling manifest -- path to tooling-manifest.json for available tools
• Validation ceiling -- maximum validation level
• Issue tracker -- for scheduled cleanup job notifications

Extract the CI/CD platform field from ## Arness config. If not present, auto-detect by scanning for .github/workflows/, .gitlab-ci.yml, or bitbucket-pipelines.yml.

Workflow

Step 1: Read Provider, Environment, and Tooling Configuration

Read the provider configuration:

Read <providers-config-path>

For each provider, extract:

• Provider name, scope, IaC tool
• Status (skip providers with Status: inactive)

Read the environment configuration:

Read <environments-config-path>

Extract:

• Promotion pipeline order (e.g., dev --> staging --> prod)
• Auto-deploy flags per environment
• Approval requirements per environment

Read the tooling manifest:

Read <tooling-manifest-path>

Check for available CI/CD-relevant tools:

• IaC CLIs (tofu, terraform, pulumi, cdk, bicep)
• Security scanners (checkov, trivy)
• Cost estimation (infracost)

Step 2: Detect Existing CI/CD

Scan for existing pipeline configurations:

Glob .github/workflows/*.yml
Glob .github/workflows/*.yaml
Glob .gitlab-ci.yml
Glob bitbucket-pipelines.yml

If existing CI/CD is found: Read and understand the existing pipeline structure. Present findings: "I found existing CI/CD pipelines: [list files]. Infrastructure pipelines will be generated as separate workflow files to extend, not replace, your existing setup."

If no existing CI/CD is found: Note: "No existing CI/CD detected. Generating infrastructure pipelines from scratch."

Step 3: Determine Pipeline Platform and Load Patterns

Based on the CI/CD platform from ## Arness config (auto-detected from CI config files, independent of the code hosting Platform):

| CI/CD Platform | Reference | |----------------|-----------| | github-actions | Read the local override or plugin default for github-actions-patterns.md. | | gitlab-ci | Read the local override or plugin default for gitlab-ci-patterns.md. | | bitbucket-pipelines | Read the local override or plugin default for bitbucket-pipelines-patterns.md. | | none | Ask the user which CI/CD platform to target. If no preference, recommend GitHub Actions for GitHub-hosted repos, Bitbucket Pipelines for Bitbucket-hosted repos, or GitLab CI for self-hosted/GitLab-hosted repos. |

Load the security checklist:

Read the local override or plugin default for pipeline-security-checklist.md.

Step 4: Invoke Pipeline Builder Agent

Invoke the arn-infra-pipeline-builder agent via the Task tool, passing the model from .arness/agent-models/infra.md as the model parameter (see plugins/arn-infra/skills/arn-infra-ensure-config/references/ensure-config.md "Dispatch convention" for fallback). Context:

--- PLATFORM CONTEXT --- CI/CD platform: [github-actions | gitlab-ci | bitbucket-pipelines] Existing CI/CD files: [list of detected files, or "none"] --- END PLATFORM CONTEXT ---

--- PROVIDER CONFIGURATION --- [For each active provider:] Provider: [name] Scope: [components] IaC tool: [tool] --- END PROVIDER CONFIGURATION ---

--- ENVIRONMENT CONFIGURATION --- Environments: [list in promotion order] Promotion pipeline: [env1 --> env2 --> env3] [For each environment:] Environment: [name] Auto-deploy: [yes | no] Approval required: [yes | no] --- END ENVIRONMENT CONFIGURATION ---

--- TOOLING CONTEXT --- Available security scanners: [checkov, trivy, or "none"] Available cost tools: [infracost, or "none"] Validation ceiling: [0-4] --- END TOOLING CONTEXT ---

--- INSTRUCTIONS --- Generate infrastructure CI/CD pipeline jobs. The number of jobs depends on the user's experience level:

Beginner (2-job pipeline):

1. PR Validation Job: Triggers on every PR that modifies IaC files (.tf, .hcl, Pulumi., cdk.json, .bicep, kubernetes/). Runs Level 0-1 checks (format, lint, validate). Plan output saved as PR comment.
2. Deploy Job: Triggers on merge to main. Applies the validated plan to the target environment.

Intermediate (3-job pipeline):

1. PR Validation Job: Triggers on every PR that modifies IaC files. Runs Level 0-2 checks (format, lint, validate, security scan if available). Plan output saved as PR comment and artifact.
2. Staging Deployment Job: Triggers on merge to main. Applies the exact plan reviewed in the PR. Respects auto-deploy flag from environment config.
3. Production Promotion Job: Manual trigger only. Requires approval gate (environment protection rules). Applies from the staging-verified state.

Expert (4-job pipeline):

1. PR Validation Job: Triggers on every PR that modifies IaC files (.tf, .hcl, Pulumi., cdk.json, .bicep, kubernetes/). Runs:
2. Level 0: Static analysis (format check, linting)
3. Level 1: IaC validation (tofu validate, pulumi preview, cdk synth)
4. Level 2: Security scan (Checkov/Trivy if available)
5. Plan output saved as PR comment and artifact for audit trail

1. Staging Deployment Job: Triggers on merge to main (or configured branch). Applies the exact plan reviewed in the PR. Respects auto-deploy flag from environment config.

1. Production Promotion Job: Manual trigger only. Requires approval gate (environment protection rules). Applies from the staging-verified state.

1. Scheduled Cleanup Job: Daily cron that checks for expired TTLs from active-resources.json. Creates issues or sends notifications (does not auto-destroy).

Security requirements (SOC 2 alignment):

• OIDC authentication for cloud providers (AWS, GCP, Azure) -- no static credentials
• Separate IAM roles per environment (staging role cannot access prod)
• Plan output stored as artifacts for audit trail
• Apply only runs the exact plan that was reviewed
• Branch protection rules enforced
• All infra changes require PR review
• Deployment logs retained

If extending existing CI/CD, add infrastructure jobs as new workflow files or new stages. Do not modify existing application CI/CD steps