Enable Code Coverage

Onboard any repository or pipeline to Harness Code Coverage (HCC) in Harness CI end-to-end. The skill inspects the build and test setup, verifies report generation across all modules, adds the codeCoverage step immediately after tests, and configures PR and default-branch baseline triggers.

Scope & Platform Requirements

• Platform Target: Harness CI only (not GitHub Actions, GitLab CI, or Jenkins). The conceptual pattern (detect tests → verify multi-module reports → upload via hcli cov upload → evaluate patch gate via hcli cov wait-until → configure PR & baseline triggers) is extensible and can be replicated on other platforms, but this skill specifically manages Harness CI pipelines and triggers.
• Autonomous Execution: Explicitly requires the Harness MCP Server (harness-mcp-v2 / harness-mcp) for autonomous discovery and write operations (inspecting repositories, checking PR checks, reading/updating pipeline YAML, and provisioning triggers).
• Build Infrastructure Compatibility: Compatible with all Harness CI build infrastructures:
  • Harness Cloud (Hosted VMs): hcli is pre-installed on the system PATH.
  • Kubernetes Build Clusters & Docker Runners: The Harness Delegate / Lite-Engine automatically bind-mounts the versioned hcli helper binary into step containers on PATH. No custom binary download or installation step is required in the pipeline.

Detail lives in references/ — read a reference only when needed:

Instructions

Follow this structured checklist:

Enable code coverage — <repo>
- [ ] 1. Discover (read-only, cached) & early-exit checks
- [ ] 2. Classify onboarding path & step placement
- [ ] 3. Validate coverage report generation (every module)
- [ ] 4. Plan & decisions (one batched approval)
- [ ] 5. Apply (pipeline, repo fix, triggers)
- [ ] 6. Verify & prerequisites
- [ ] 7. Quality-check summary

Step 1: Discover & Early-Exit Checks

1. Accept a repository identifier, pipeline identifier, or Harness URL.
2. Auto-extract org_id and project_id. Retrieve default branch (main or master), git connector, and existing PR checks via harness_list(resource_type="pr_check").
3. Fetch candidate pipeline YAML via harness_list and harness_get.
4. Early exits:
   • If test command already contains hcli cov upload or uses codeCoverage, skip wiring.
   • If PR trigger and baseline trigger exist, skip trigger creation.

Step 2: Classify Onboarding Path & Step Placement

• Step Placement Rule: The codeCoverage step must be placed immediately after the test step within the same stage (reports must exist before upload). Never place it in parallel before tests run.
• Track A (Extend Existing): Insert the codeCoverage step (from templates/codeCoverage.yaml) immediately after the unit-test step in the existing pipeline.
• Track B (No CI Pipeline Exists): Offer to scaffold a standard build/test/coverage pipeline for the detected language.

Step 3: Validate Coverage Report Generation (Critical)

HCC analyzes only lines present in uploaded coverage reports; it does not analyze raw git source. Verify that every module in multi-module setups (Maven <modules>, Gradle subprojects, npm workspaces, go test ./..., pytest) produces a supported report format:

• Java/Kotlin: JaCoCo XML (jacoco.xml)
• Python, JS/TS: LCOV (lcov.info) or Cobertura (coverage.xml)
• Go: Go coverage profile (coverage.out)

If any module lacks reports, prepare the build-file fix using recipes in references/language-recipes.md.

Step 4: Plan & Batched Approval

Show all proposed diffs together (pipeline YAML, trigger YAMLs, repo PR diff). Ask for explicit chat approval before making any changes. In dry-run mode, stop here and produce the plan summary.

Step 5: Apply Approved Changes

• Pipeline: Update via harness_update(resource_type="pipeline", body={ "yamlPipeline": "<YAML string>" }).
• Repo-side fix: If approved, open a PR with the required build-file configuration.
• Triggers: Create the missing PR trigger (PullRequest webhook, 80% patch gate) and Baseline trigger (Push webhook on default branch) via harness_create(resource_type="trigger").

Step 6: Verify & Prerequisites

• Ensure Code Coverage is enabled on the account.
• If ACCESS_DENIED is returned, flag the missing permission and resource scope directly to the user.
• Success criteria: coverage-patch check appears on PRs; baseline trigger runs on merges to the default branch.

Step 7: Quality-Check Summary

Always conclude with this fixed summary:

Quality check — <repo>   [mode: normal | dry-run]

1. PR coverage
   - Patch coverage (coverage-patch): working | failing | not yet verified | planned — <evidence>
   - Project coverage (coverage-project): working | failing | not yet verified | planned — <evidence>
   - PR trigger: existing | created (<id>) | planned
   - Modules with reports: <n>/<total> — <missing modules, if any>

2. Branch scans / repo coverage (baseline)
   - Baseline trigger on <default branch>: existing | created (<id>) | planned
   - Baseline execution: <link + status> | pending until a PR is merged
   - Monitoring: <user will monitor the first post-merge run | offered to check it after merge>

3. Fixes made
   - Repo-side fix: PR <link> | manual instructions given | none needed
   - Pipeline: PR/commit <link> (REMOTE) | inline update — <diff summary> | none
   - Triggers: created <ids> (inline, no PR) | already existed
   - Outstanding prerequisites: <e.g. account coverage enablement, deferred exclusions>

Examples

Example 1: Onboard by Pipeline URL

/enable-code-coverage https://app.harness.io/ng/account/l7B_kbSEQD2wjrM7PShm5w/all/orgs/default/projects/demo/pipelines/build_pipeline

The agent inspects the pipeline, detects the mvn test step, confirms JaCoCo report generation, drafts the codeCoverage step immediately after test execution, prepares PR and baseline triggers, and presents diffs for approval.

Example 2: Dry Run on a Repository

/enable-code-coverage Dry run on repository analytics-service in org default, project core.

The agent inspects the repository and pipelines, validates multi-module coverage outputs, and prints the plan and quality summary without performing any write calls.

Performance Notes

• Always inspect existing checks via harness_list(resource_type="pr_check") to avoid redundant runs.
• Keep the coverage step within the test stage to reuse the checkout and workspace without re-downloading source.
• Configure exclusions in the Code Coverage module settings rather than cluttering pipeline YAML.

Troubleshooting