feat: delete Workflow CR from K8s upon successful archiving

[qa-denis-huber]

Summary

Add a configuration option to automatically delete Workflow CRs from Kubernetes upon successful archiving to
the database.

Current mechanisms don't provide this:

• archiveTTL - deletes from the database, not K8s
• ttlStrategy - deletes from K8s based on time, not archive status
• retentionPolicy - deletes from K8s based on count, not archive status

Using ttlStrategy with archiving is a time-based workaround, not an event-based guarantee. There's currently
no way to delete the K8s resource strictly upon successful archiving.

Use Case

• Guaranteed cleanup after archival: Ensure workflows are only removed from K8s once safely persisted to the
  database
• Reduce cluster resource usage: Automatically clean up CRs without relying on arbitrary time delays
• Avoid data loss: Time-based TTL may delete workflows before archiving completes (or archive may fail
  silently)

Proposed Solution

Add a new configuration option in the workflow-controller-configmap:

persistence:
  archive: true
  deleteOnArchive: true  # New option: delete Workflow CR after successful archiving

Behavior:

1. If archiving succeeds AND deleteOnArchive: true: delete the Workflow CR from K8s
2. If archiving fails: retain the Workflow CR

---

Message from the maintainers:

Love this feature request? Give it a 👍. We prioritise the proposals with the most 👍.

[yugannkt]

Hello @Joibel @shuangkun @MasonM

Feasibility Analysis & Proposal

Current State Verification ✅

I've analyzed the codebase and can confirm the issue description is accurate:

Existing cleanup mechanisms:

• archiveTTL → Deletes from database only, not K8s
• ttlStrategy → Time-based deletion from K8s (doesn't check archive status)
• retentionPolicy → Count-based deletion from K8s (doesn't check archive status)

The Gap: The GC controller has no awareness of workflow archive status labels. There's currently no way to delete a Workflow CR from K8s only after successful archiving - it's impossible to achieve with existing code.

---

Proposed Solution

Add a new configuration option to workflow-controller-configmap:

persistence:
  archive: true
  deleteOnArchive: true  # NEW OPTION
  postgresql:
    # ... existing config ...

Use Case:
Organizations running thousands of workflows need efficient K8s resource management while ensuring data safety. Current time-based TTL creates a race condition between archiving and deletion.

---

Questions for Maintainers

1. Does this approach align with Argo Workflows' design philosophy?
2. Should we add validation to prevent using deleteOnArchive with ttlStrategy simultaneously?
3. Any concerns about the implementation approach?

---

Request

If this proposal looks reasonable, I'd be happy to work on a PR implementing this feature. Please let me know if:

• The approach needs any adjustments- This feature should be prioritized or if there are alternative solutions

Thanks.