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):

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 with:

--- 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:

   • Level 0: Static analysis (format check, linting)
   • Level 1: IaC validation (tofu validate, pulumi preview, cdk synth)
   • Level 2: Security scan (Checkov/Trivy if available)
   • Plan output saved as PR comment and artifact for audit trail

2. 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.

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

4. 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. --- END INSTRUCTIONS ---

Verify that the pipeline builder agent returned at least one pipeline configuration file. If no files were produced, follow the "Pipeline builder returns empty output" error handling procedure before proceeding.

Step 5: Invoke Security Auditor for Pipeline Review

Invoke the arn-infra-security-auditor agent via the Task tool with:

--- FILES TO AUDIT --- [Generated pipeline configuration files from Step 4] --- END FILES TO AUDIT ---

--- AUDIT CONTEXT --- Audit type: CI/CD pipeline security review Provider(s): [list] Compliance: SOC 2 alignment --- END AUDIT CONTEXT ---

--- TOOLING CONTEXT --- Available security scanners: [checkov | trivy | none -- from tooling manifest] Available secret scanners: [trufflehog | gitleaks | none -- from tooling manifest] --- END TOOLING CONTEXT ---

--- INSTRUCTIONS --- Review the generated pipeline configurations for security issues:

• Secrets exposure in logs or artifacts
• Missing OIDC authentication (static credentials used instead)
• Overly permissive IAM roles for CI runners
• Unpinned action versions or container images
• Missing branch protection enforcement
• Insufficient separation of duties between environments --- END INSTRUCTIONS ---

If security issues are found: Apply fixes to the generated pipeline before presenting to the user. Note what was changed: "The security auditor found [N] issues. I've applied fixes: [list]."

Step 6: Present Generated Pipeline for Approval

Present each generated pipeline file to the user:

"Here are the generated infrastructure CI/CD pipelines:

Platform: [GitHub Actions | GitLab CI | Bitbucket Pipelines] Security audit: [Passed | N issues found and fixed]

[For each file:] [filename]:

[generated content]

Jobs included:

1. PR Validation -- Runs on IaC PRs with Level 0-2 checks
2. Staging Deploy -- Triggers on merge to main
3. Production Promotion -- Manual trigger with approval gate
4. Scheduled Cleanup -- Daily TTL check

Required setup:

• [List of secrets/variables to configure in CI/CD settings]
• [OIDC provider configuration steps]
• [Branch protection rule recommendations]

Ask (using AskUserQuestion):

"How would you like to proceed with the generated pipelines?"

Options:

1. Approve and write -- Write all pipeline files to the project
2. Edit -- Make changes before writing
3. Regenerate -- Adjust the configuration and regenerate

Step 7: Write Files and Summarize

Upon user approval, write generated pipeline files to the appropriate locations:

• GitHub Actions: .github/workflows/infra-*.yml
• GitLab CI: .gitlab-ci-infra.yml or included files
• Bitbucket: extend bitbucket-pipelines.yml

Present the summary:

Infrastructure Pipeline Summary:

• Platform: [platform]
• Jobs: PR validation, staging deploy, prod promotion, scheduled cleanup
• Files created: [list with paths]
• Security audit: [result]
• OIDC configured for: [providers]
• Environments: [list with promotion rules]

Required manual setup:

1. Configure OIDC trust relationships in [provider(s)]
2. Set up environment protection rules for production
3. Configure the following CI/CD secrets/variables: [list]

Recommended next steps:

"Infrastructure CI/CD is ready. Here is the recommended path:

1. Configure OIDC: Follow the setup instructions above for [provider] OIDC trust
2. Set up environments: Run /arn-infra-env to configure environment isolation and promotion
3. Manage secrets: Run /arn-infra-secrets to set up secrets management for your pipelines
4. Deploy: Run /arn-infra-deploy to deploy to your first environment

Or run /arn-infra-wizard for the full guided pipeline."

Error Handling

• ## Arness config missing: Suggest running /arn-infra-wizard to get started. Stop.
• CI/CD platform is none: Inform the user that no CI/CD platform was detected. Suggest running /arn-infra-init to re-detect, or specify a target platform manually. Stop.
• No providers configured: Suggest running /arn-infra-init to configure providers. Stop.
• Pipeline builder agent fails: Report the error. Fall back to generating basic pipeline configurations directly using the loaded reference patterns. Present with a note: "Generated using fallback patterns -- review carefully before use."
• Pipeline builder returns empty output: Inform the user and retry with additional context. If retry fails, offer to generate a minimal pipeline template manually.
• Security auditor fails: Present the generated pipeline without security review. Warn: "Security audit could not be performed. Review the pipeline manually against the security checklist before committing."
• Existing CI/CD conflicts: If the generated pipeline would conflict with existing workflows (duplicate triggers, overlapping jobs), present both and ask the user how to resolve.
• OIDC not supported for provider: Fall back to documenting manual secret configuration. Warn: "OIDC is not available for [provider]. Static credentials will be used. Ensure proper rotation and least-privilege access."
• Re-running is safe: Re-running regenerates pipeline files (after user approval). Existing infrastructure pipelines are shown in a diff before overwriting. Application CI/CD is never modified.