Plugin Suites

What A Suite Is

A plugin suite bundles one build ecosystem and everything that analyzes its output. The maven suite ships the build stage of the evaluation pipeline (the job and the container image that compiles a student project) together with the analysis plugins that run against that build: PMD, Surefire, JaCoCo/PIT. A gradle suite does the same for Gradle projects, and the custom suite is the generic fallback for courses that build something else.

You enable a suite, not a list of individual plugins. The suite author has already picked the plugin versions that work together with that build stage, so you do not have to assemble a working combination yourself.

Two things follow from this for daily work:

• A plugin is addressed as <suite>/<plugin>, for example maven/pmd. That pair is also what you see in pipeline job names (maven:pmd), in result directories (plugin-results/maven/pmd/), and in plugin configuration paths (.divekit/plugins/maven/pmd/).
• maven/pmd and gradle/pmd can be active in the same course without colliding.

Enable A Suite

divekit plugin add maven

Divekit reads the suite at its newest release, resolves every plugin the suite pins, and writes the result into the origin’s plugin state. Plugin jobs are composed into the evaluation pipeline directly; there are no separate child pipeline files to manage anymore.

Check what an origin currently runs:

divekit plugin list

Configure the suite when its plugins need settings, for example coverage thresholds:

divekit plugin configure maven

Each plugin brings its own wizard, and Divekit runs the wizards of the enabled plugins in one pass, so a course’s plugin settings are made in a single session. To revisit one plugin, address it directly:

divekit plugin configure maven/jacoco-pit

Answers are written below .divekit/plugins/<suite>/<plugin>/ in the eval authoring tree and travel into every evaluation repository from there.

What Gets Locked

When a suite is enabled or updated, Divekit resolves each plugin to an exact version and to the digest of the container image that version published, and stores both in the origin’s plugin state:

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

Nothing is resolved while a pipeline runs. A plugin author publishing a new patch release, or re-tagging an existing image, therefore cannot change what a running course evaluates. Two students who push in different weeks are graded by the same plugin build, and a re-run of an old pipeline produces the same result as the original run. The locked state is also the full description of what the course runs, which is what makes a course reproducible from its origin repository alone.

Suites pin their plugins with ranges (^1.2.0, ~2.0.1, or an exact tag), but that is an authoring convenience for the suite author. In a course, only exact versions exist.

Turn Single Plugins On And Off

A suite’s plugin set is a curated default, not an obligation. Toggle individual plugins with the <suite>/<plugin> form:

divekit plugin disable maven/jacoco-pit
divekit plugin enable maven/jacoco-pit

A disabled plugin keeps its locked version and stays in the state file; only its job leaves the pipeline. Re-enabling it does not resolve a new version.

You cannot re-pin a single plugin to a different version. Version selection belongs to the suite, because a per-course version override would recreate exactly the untested combination of build stage and analysis plugin that suite-level pinning exists to prevent. When you need a plugin the suite does not ship, attach it to the suite as an external plugin from your own source instead; it then gets the same locking and validation as a curated one.

Update

divekit plugin update

This is the only command that moves a locked version or image digest. It re-resolves the suite’s pins, picks up the plugin releases the ranges now allow, and rewrites the locks. Run it when you want new plugin versions, not on a schedule during a running assignment.

For repositories that already exist, push the change out afterwards:

divekit plugin update
divekit patch ci -d ST2M4

Use divekit patch ci -d ST2M4 --dry-run first to see what would change.

File Edits And Hooks

Some plugins need an entry in a file your course owns. JaCoCo/PIT, for example, only works when the student project’s pom.xml carries its plugin fragment. Suites can perform such edits themselves instead of leaving them as manual setup steps in a README.

The rules around that are the same for every plugin:

• Divekit shows every proposed change as a diff and writes nothing until you confirm it. A plugin cannot quietly modify a file you maintain.
• Disabling the plugin reverses what enabling applied. Divekit records what it wrote under .divekit/hooks/journal/<suite>/<plugin>.json and reverses from that record, so the correct block is removed even when the suite has changed its fragment in the meantime.
• A file that a plugin created and that you have edited since is kept, not deleted, and the command reports it so you can decide.
• A plugin from a source that is not marked trusted asks once, before its first run, whether its edit logic may run on your machine at all. The answer is stored next to that source in ~/.divekit/plugin-sources.json. The default Divekit plugin source is trusted and does not ask.
• A run that cannot ask, for example inside a script, needs -y. Without it the command stops instead of editing course files unattended.

If a plugin’s source is unreachable when you enable it, the pipeline job is still switched on and no files are edited; the next enable against a reachable source applies the edits.

Related

• Plugins
• Migrate To Plugin Suites
• Evaluation Pipeline
• divekit plugin --help