Reference Available now

Build plugin configuration

The plugin works with zero configuration — it scans everything and writes records to target/codevidence/ (Maven) or build/codevidence/ (Gradle). Every option below is optional.

Options

Field	Type	Required	Description
`serviceId`	`String`	No	Value written to `provenance.serviceId`. Defaults to the Maven artifact ID / Gradle project name.
`schemaVersion`	`String`	No	Evidence-record schema version. Defaults to `0.1`.
`commit`	`String`	No	Manual commit override. Auto-detection (CI env vars, then `git rev-parse HEAD`) is the default; a manual value is always tagged `commitSource: "manual-override"` so it’s never mistaken for auto-detected.
`buildId`	`String`	No	Manual build-id override. Auto-detected from CI env vars, else a generated `local-…` id.
`apiKey`	`String`	No	Your Codevidence API key. Sent as `Authorization: Bearer …` with each publish request. When unset here, the `CODEVIDENCE_API_KEY` environment variable is used. With no key from either source, nothing is published — evidence stays local-file-only.
`evidenceEndpoint`	`String`	No	Where records are POSTed. Defaults to the hosted Codevidence API (`https://app.codevidence.com/api/v1/evidence`). Override it to point at a self-hosted ingestion service that accepts the same request.

Gradle (`codevidence` extension)

build.gradle.kts

codevidence {
    serviceId = "checkout-service"
    // all optional:
    // schemaVersion = "0.1"
    // commit = "…"        // manual override; auto-detected otherwise
    // buildId = "…"       // manual override; auto-detected otherwise
    // apiKey = "…"        // usually the CODEVIDENCE_API_KEY env var instead
    // evidenceEndpoint = "https://app.codevidence.com/api/v1/evidence"  // override to self-host
}

Maven (`-D` properties)

Each option maps to a codevidence.* property (-Dcodevidence.commit=…, -Dcodevidence.apiKey=…), so overrides can come from CI without editing the POM. The API key is normally supplied as an environment variable rather than a property:

# CI — publish this build's evidence to Codevidence
export CODEVIDENCE_API_KEY=cev_acme_xxxxxxxx
mvn verify

Publishing to Codevidence

Both goals publish — one declared record per @ComplianceControl, one verified record per @VerifiesControl assertion — only when an API key is configured (the apiKey option or the CODEVIDENCE_API_KEY environment variable). With no key, the plugin makes no network call and evidence is local-file-only.

Records are POSTed as JSON to evidenceEndpoint, which defaults to https://app.codevidence.com/api/v1/evidence.
The key is sent as Authorization: Bearer <key>. The endpoint acknowledges each record with 202 Accepted.
A non-2xx response or a transport error is logged as a warning and never fails the build.
Point evidenceEndpoint at your own service to self-host ingestion — see the request contract at https://app.codevidence.com/api/openapi.json (interactive: /api-docs).

Your team then signs in at app.codevidence.com to review controls against the code that implements and verifies them.

Provenance is never fabricated

If no CI variable matches and git rev-parse HEAD can’t resolve a commit, the record gets commit: null and commitSource: "unavailable", and the build logs a warning — rather than inventing a placeholder. See the Declared and Verified schemas.

What it doesn’t do

There’s no option to make the plugin read your source or execute your production code — that’s an architectural constraint, not a toggle. The only network call it ever makes is the evidence POST above, and that payload is the evidence record JSON, never source. See why bytecode, not source.