fix: drop additional command line arguments the step sets for itself

[NickJosevski]

Follow-up to #220, which is where six of these stopped being stripped.

What's wrong

Every command CommandHelper builds sets --project, --space and --output-format from the step's own fields. None of the three ignore lists covered them consistently, so a copy in Additional command line arguments is appended after the plugin's own and the CLI keeps the last one.

--output-format is the one with teeth — these commands are run for their JSON, which CommandUtils.getReleaseVersion and getServerTaskId parse. Verified against a live Octopus with --output-format table in the field:

step	result
release create --output-format json --output-format table	table wins; release created, exit 0
isCreateReleaseCommand(output)	false — no capital-V Version in table output, so version extraction is skipped silently rather than throwing
getVersion("", null)	""
release deploy (built with no --version)	release version must be specified

The release is created, nothing complains at the step that caused it, and the deploy fails with a message unrelated to the cause.

--space and --project are quieter but worse in kind: they silently retarget the command away from what the step's fields say.

Restoration vs new coverage

Being honest about which is which — measured by running both matching implementations over all three lists:

	-p	--project	-s	--space	-f	--output-format
stripped from release create	regressed by #220	never	regressed	never	regressed	never
stripped from release deploy	regressed	never	never	never	regressed	never
stripped from runbook run	still covered	still covered	regressed	still covered	never	never

The six regressions were accidental substring matches under the old String.contains (-p inside --force-package-download, -s inside --skip/--snapshot, -f inside --force-* and --release-notes-file). #220 correctly stopped matching substrings, and so stopped covering them.

Approach

Rather than restore the accident, collect the arguments the plugin owns into one set and fold it into all three per-command lists via commandArgumentSet, so a fourth command gets it by construction:

private static final Set<String> pluginOwnedArguments =
    argumentSet("-p", "--project", "-s", "--space", "-f", "--output-format");

The now-redundant -p/--project/--space entries come out of the runbook list, leaving one source of truth.

--version is deliberately excluded: release create takes it from the Release number field but runbook run has no such flag, and unlike these three it was never covered by the old matching either — so including it would be a new behaviour change rather than part of this one.

Tests

One parameterised test over all six forms, asserting each of the three commands keeps exactly one --project, --space and --output-format with the step's own values. All six cases fail against the unfixed source. CommandHelperTest is 27 tests, and main's two runbook tests pass unchanged against the trimmed runbook list.

./gradlew check distZip green.

Verified against a live Octopus

Commands generated from CommandHelper itself, then executed against a local instance with a prompted variable, for --output-format table, -f table, and --space Other --project Other — each creates and deploys cleanly with the prompted variable arriving (PROBE ImageTag=[1.5.2]). The runbook run path shares the same code and is covered by unit tests only, since the probe project has no runbook.

🤖 Generated with Claude Code