Supported Argo Versions

Every push to main submits the real examples/e2e workflow to a live Argo + MinIO per version and asserts it Succeeded. The support matrix is therefore not a claim - it is a continuously verified result.

Argo Workflows maintains the two most recent minors; cargo-athena tracks that plus the minimum that still works. All three are blocking CI jobs (no continue-on-error).

Why ≤ 3.5 is unsupported

cargo-athena emits one WorkflowTemplate per template, wired via templateRef. Argo’s submit-time validator before 3.6 cannot resolve {{tasks.X.outputs.*}} across a templateRef boundary, so any multi-step workflow fails instantly with failed to resolve {{tasks.a.outputs.…}}.

This was fixed in Argo 3.6: the emitted YAML is correct and passes 3.6/3.7/4.0 unchanged. Older versions may still work for trivial cases; use at your own risk.

What’s degraded on 3.6

The args-offload feature (Argo PR #15265) shipped in 3.7. On 3.6 the controller does not stage large arguments via ConfigMap, so any task whose substituted args[] cross the kernel exec ARG_MAX (~128 KB combined) fails with argument list too long. Use Artifact<T> for any parameter that may exceed that threshold if you need to run on 3.6. 3.7 and 4.0 are unaffected: the controller stages large args automatically; cargo-athena’s runtime reads the offloaded value back transparently.

Live badges

GitHub has no per-matrix-job badge, so each matrix job publishes its pass/fail to a gist and the README renders shields.io endpoint badges from it - the badges at the top of the README are that live e2e result.