The landscape shows more projects, time to read through all their marketing crap (again), and find new toys to play with.
You could build a full ci/cd pipeline from all this: Argo Events to trigger builds in Argo Workflows, Argo Workflows updating a shared manifest, Argo CD triggering new deployments, new deployments go through Argo Rollouts.
Workflows is very barebones when it comes to CI though, really is generic workflow thing.
A DAG of steps (k8s pods?) triggered by cli
Reconcile git repo state of manifests with cluster state.
Replace deployment resource with rollout resource. Will do canary / blue-green on new versions
Takes / listens for events, triggers requests / workflows / rollouts
Managed control plane + self hosted runners (an executable you run). Parallel by default, allows manual input step, steps are just scripts/commands you run, no isolation from host.
Self hosted control plane + runners (ex a docker image). Each step is a docker container / k8s pod / local exec / ssh session. Volumes keep state between each step.
Controller for adding a canary phase between deployment rollouts. Add canary resource specifying a deployment, and new changes to the deployment will go through canary stages first before being promoted.
Operator for reconciling a declaritive k8s state in a repo with actual state. Can auto update images based on registry metadata (and sync back repo state).
toolkit aka flux v2
Set of controllers that watch repositories for changes and reconcile state with helm / kustomize
Self hosted control plane + runners. Nothing too interesting(?)
Looks like a very complex, UI centered way of managing deployments.
Maybe it's something like flagger but manages more of the lifecycle and provides automated actions such as rollbacks? Architecture looks overly complex, docs aren't clear especially on the triggers for deployment, uses mongodb.
Similar in scope to Argo Workflows + Events, Pipelines are generic DAG workflows, Triggers trigger Pipelines.