Plugin Configuration JSON

Plugin configuration files are owned by individual Evaluation Pipeline plugins. Divekit writes them when a plugin declares a configuration wizard and a user runs divekit plugin configure <plugin>.

The exact keys belong to the plugin. Divekit only controls where the file is stored, how wizard fields are converted to JSON, and optional result metadata such as schemaVersion.

Default Location

For a wizard result path of config.json, Divekit writes the authoring file to:

.divekit/eval-pipeline/eval/.divekit/plugins/<plugin-id>/config.json
.divekit/distributions/<distribution>/eval-pipeline/eval/.divekit/plugins/<plugin-id>/config.json

When evaluation repositories are generated, the same file is available to plugin jobs at:

.divekit/plugins/<plugin-id>/config.json

A plugin can choose another result path through result.path in configure.wizard.json. Relative paths are resolved below .divekit/plugins/<plugin-id>/. Paths that start with / are resolved from the evaluation repository root.

Example

This example shows the JSON generated from a wizard that collects a list of test tasks. The schemaVersion key comes from result.schemaVersion. The tasks array comes from an objectList field. Dotted child keys such as coverage.lineCoverage become nested objects inside each list entry.

{
  "schemaVersion": 1,
  "tasks": [
    {
      "name": "unit-tests",
      "command": "./gradlew test",
      "coverage": {
        "lineCoverage": 0.8,
        "branchCoverage": 0.7
      },
      "classesToInclude": [
        "de.thkoeln.example.*"
      ],
      "failOnMutationSurvivors": true
    },
    {
      "name": "integration-tests",
      "command": "./gradlew integrationTest",
      "coverage": {
        "lineCoverage": 0.65
      },
      "classesToInclude": [
        "de.thkoeln.example.integration.*"
      ],
      "failOnMutationSurvivors": false
    }
  ],
  "report": {
    "mode": "summary"
  }
}

The plugin reads and interprets this file during its CI job. For example, it could iterate over tasks, run each configured command, apply the configured coverage thresholds, and emit normalized report results.

Wizard Field Mapping

The wizard writes one JSON object. Each top-level field key becomes a key in that object. Dotted keys create nested objects:

{
  "key": "report.mode",
  "type": "select"
}

writes:

{
  "report": {
    "mode": "summary"
  }
}

objectList fields write arrays of objects. Child field keys are relative to the individual array entry:

{
  "key": "tasks",
  "type": "objectList",
  "fields": [
    { "key": "name", "type": "string" },
    { "key": "coverage.lineCoverage", "type": "percent" }
  ]
}

writes:

{
  "tasks": [
    {
      "name": "unit-tests",
      "coverage": {
        "lineCoverage": 0.8
      }
    }
  ]
}

objectList fields cannot contain another objectList. Use dotted child keys when each list entry needs nested object values.

Notes

• Plugin configuration files are plugin-owned. Divekit does not validate their semantic meaning after the wizard has produced structurally valid JSON.
• divekit plugin configure <plugin> --yes preserves existing values and applies wizard defaults for missing values. Required fields still need an existing value or a default.
• Optional percent, number, and integer wizard fields with an empty value are omitted from the generated configuration instead of being stored as zero.
• Reconfiguring an existing objectList lets the user edit, keep, or remove each existing entry, then add more entries.
• Keep the wizard schema and the plugin’s parser compatible. If the plugin changes the meaning of existing keys, update schemaVersion or provide plugin-side compatibility handling.

Related pages:

• Configuration Wizards
• Plugin Contract