Use case: Purge all selected process definitions

[grafvonb]

Use case: Purge all selected process definitions

Status

• Implemented
• Implemented command: c8volt ops purge all-process-definitions

Proposed command

c8volt ops purge all-process-definitions [flags]

Aliases:

c8volt ops purge all-pds [flags]
c8volt ops purge apd [flags]

Operator goal

• Delete selected process-definition versions through one audited workflow.
• Discover candidate process definitions, preview process-instance impact, block unsafe active-instance deletion unless explicitly forced, and report the final outcome.

When to use

• Environment / prerequisite: configured Camunda profile, reachable Camunda cluster, process-definition service, process-instance service, and resource deletion support available
• Trigger: cleanup of old deployments, test fixture cleanup, maintenance after version rollouts, removal of latest or specific process-definition versions
• User role / audience: Camunda operators, maintainers, CI/preflight cleanup automation

Manual workflow today

c8volt get pd [process-definition filters...]
c8volt delete pd --key <candidate-process-definition-key>

Desired high-level workflow

1. Discover candidate process definitions using get pd-style selectors.
2. Freeze the unique candidate process-definition keys.
3. Build the existing process-definition delete preview.
4. Count affected process instances and active process-instance blockers.
5. If --dry-run is supplied, report the plan and mutate nothing.
6. If active instances are affected, refuse mutation unless --force is supplied.
7. Confirm interactively, or proceed through --auto-confirm / --automation.
8. Delete selected process definitions through the existing process-definition deletion service.
9. Report deletion status and final outcome.
10. Write an audit report when requested.

Inputs and filters

• Required inputs: none beyond active profile/config
• Optional filters: --key, --bpmn-process-id, --pd-version, --pd-version-tag, --latest
• Count / limit / batch / worker controls: --workers, --no-worker-limit, --fail-fast
• Execution controls: --dry-run, --force, --no-wait, --auto-confirm, --automation, --json
• Report controls: --report-file, --report-format markdown|json
• Tenant/profile/config considerations: use active --config, --profile, and --tenant behavior consistently with existing commands

Guardrails

• Dry run expectations: discover matching process definitions, preview deletion impact, show affected process-instance count, and mutate nothing
• Report expectations: support --report-file and --report-format markdown|json
• Confirmation behavior: prompt before deletion unless implicitly confirmed
• --auto-confirm behavior: allows deletion without prompts
• --automation --json behavior: deterministic JSON stdout; logs/progress on stderr or suppressed according to existing patterns
• Force behavior: active process-instance impact blocks deletion unless --force is supplied
• Sensitive data handling: reports should include operational metadata and keys, not unrelated variables or sensitive config details

Success criteria

• Candidate process definitions are discovered.
• Duplicate candidate keys are deduplicated.
• Delete impact is planned before mutation.
• Active process-instance blockers are reported.
• Deletion is skipped in dry-run mode.
• Real deletion is submitted only after confirmation or automation.
• Final outcome is reported.

Failure behavior

• Fail before mutation for invalid selectors such as invalid --key, non-positive --pd-version, or invalid --workers.
• Fail before mutation if active process instances are affected and --force is not supplied.
• Report failed or partial deletion if the lower-level process-definition deletion service fails after submission.
• Preserve existing report files unless the run is already confirmed for mutation.

Output and report shape

• Human output should show: selection filters, candidate process-definition count, latest-only scope when used, process-definition/version impact, affected process-instance count, active-instance blockers, deletion status, final outcome
• JSON output should include: structured discovery, delete plan, deletion result, notices, errors, and outcome
• Audit report should include: timestamps, dry-run flag, c8volt version, Camunda version, tenant, profile identity, selection filters, candidate definitions, duplicate candidates, delete-plan items, affected and active process-instance counts, deletion items, flags, notices, errors, final outcome

Open questions

Notes / gotchas

• --latest narrows candidate discovery to latest matching process definitions.
• --force may cancel affected active process instances according to existing process-definition deletion behavior.
• The workflow should reuse existing services and command facades, not shell out to c8volt commands.