create-pipeline

Create Pipeline

Generate Harness v0 Pipeline YAML and optionally push to Harness via MCP.

Instructions

1. Analyze codebase (if source code is available) - Scan the project to auto-detect language, build tools, test frameworks, containerization, deployment manifests, and target infrastructure. Use the detection tables and decision tree in references/codebase-analysis.md to determine:
   • Language and runtime version (package.json → Node.js, go.mod → Go, pom.xml → Java, etc.)
   • Build commands and base images
   • Test framework and report format (Jest → JUnit, pytest → JUnit XML, etc.)
   • Linter and formatter (ESLint, Prettier, Ruff, etc.)
   • Dockerfile presence and registry type (Docker Hub, ECR, GCR, ACR)
   • Deployment manifests → Harness service/deployment type (k8s manifests → Kubernetes, Chart.yaml → NativeHelm, task-definition.json → ECS, serverless.yml → ServerlessAwsLambda)
   • Existing CI/CD configs for migration (GitHub Actions, Jenkins, GitLab CI, etc.)
2. Clarify requirements - Confirm detected settings with the user. Ask about anything that couldn't be auto-detected — do not guess or use placeholders. If the user's request is ambiguous, ask before generating YAML. Examples of what to ask when missing:
   • Deployment target / infrastructure: region (e.g. us-east-1), cluster name or ID, account ID (e.g. AWS account for ECR/ECS)
   • Registry: which registry (Docker Hub, ECR, GCR, ACR), registry identifier/URL, repo path
   • Cloud provider: which account, region, and resource identifiers for connectors/infrastructure
   • Approval gates, notification channels if relevant Critical rule: Never hardcode placeholder values (e.g. 123456789012, us-east-1, my-cluster) for deployment target, region, registry, or cluster when the user did not specify them — ask the user instead. If the user did not specify region, account ID, cluster, or registry (e.g. "deploys to ECS" with no region or cluster), ask the user for those values before generating YAML.
3. Select native steps - Always prefer Harness native steps over Run or ShellScript steps. Consult references/native-steps.md for the full mapping. Key rules:
   • Docker build/push → use BuildAndPushDockerRegistry / BuildAndPushECR / BuildAndPushGCR / BuildAndPushACR (never Run: docker build && docker push)
   • K8s deploy → use K8sRollingDeploy / K8sBlueGreenDeploy / K8sCanaryDeploy (never Run: kubectl apply)
   • Helm deploy → use HelmDeploy (never Run: helm upgrade --install)
   • ECS deploy → use EcsRollingDeploy (never Run: aws ecs update-service)
   • Terraform → use TerraformPlan / TerraformApply (never Run: terraform apply)
   • Security scanning → use native STO steps (AquaTrivy, Snyk, Sonarqube, Semgrep, etc.)
   • Uploads → use S3Upload / GCSUpload (never Run: aws s3 cp)
   • Approvals → use HarnessApproval / JiraApproval (never polling scripts)
   • Ticketing → use JiraCreate / ServiceNowCreate (never Run: curl)
   • Use Run steps only for custom build/test/lint commands with no native equivalent
   • Test steps: Any Run step that runs unit or integration tests must include a reports block (e.g. type: JUnit, spec.paths) so Harness can capture results; see references/codebase-analysis.md for framework → report path.
4. Generate valid YAML following the structure below, using the detected build/test/deploy commands. Validation rules: (a) Stage names must match ^[a-zA-Z_0-9-.][-0-9a-zA-Z_\\s.]{0,127}$ — use only letters, numbers, spaces, hyphens, underscores, or periods (no commas). (b) Every CI and CD stage must include a failureStrategies array (Approval stages do not require one). For CI use MarkAsFailure (never Ignore — it hides failures); for CD use StageRollback.
5. Optionally create via MCP — First verify the project exists (see "Creating via MCP" section below), then use harness_create with resource_type pipeline and body: { yamlPipeline: "<YAML string>" }