[briankane]

Stack 23/23 · after #977 · last in the stack

Targets main but builds on #977, so the earlier stack commits show here too: review the last commit only. Merge after #977.

Description of your changes

A workflow step or step group with forEach runs once per item (kubevela/pkg#142, kubevela/workflow#261, kubevela/kubevela#7396), and can name each item by a key (kubevela/pkg#154, kubevela/workflow#273, kubevela/kubevela#7468). VelaUX dropped forEach when it copied steps, so a loop synced from the cluster ran once on the next deploy, and a run's passes matched nothing it knew. VelaUX now keeps loops, records them, and lets you build and follow them.

Run view. A loop is a stacked card: a segment per item when closed, a lane per item when open, labelled by the item, with Approve on a waiting pass.

Studio. Loop in the Add menu (greyed inside a group, since only a top-level step takes forEach), Repeat on a card's tools, and a strip on each loop with its items and mode.

The wizard gains an Items stage: a list typed in (a table, or YAML), an earlier step's output, or, in an application, a $( ) expression; one item at a time or all at once. Steps in a loop are offered each.item, each.index and each item key as inputs.

A key names each item's passes after values in the item (rollout-us-east-deploy rather than rollout-0-deploy). The Items stage takes one, offered from the list's columns and checked as the controller checks it; a keyed loop's lanes are labelled by their keys.

Pipelines get the same studio and run view.

Server side:

• Sync, deploy and the API keep forEach, including key.
• A loop's run record starts with no sub-steps and takes its passes from the status, each with the item it ran for (the engine's own IterationIndex) and the alias of the body step it repeats (IterationTemplate). The items, and a keyed loop's labels, are the ones the engine stored in the workflow context. Before this, a looped group's record kept its body once, never started.
• A pipeline run carries the same per loop (loops on the run and its status), and no longer pads a loop with its body steps.

Fixes #

I have:

• Read and followed KubeVela's contribution process.
• Related Docs updated properly. In a new feature or configuration option, an update to the documentation is necessary.
• Run yarn lint to ensure the frontend changes are ready for review.
• Run make reviewableto ensure the server changes are ready for review.
• Added backport release-x.y labels to auto-backport this PR if necessary.

How has this code been tested

• Go: forEach round trips through sync, deploy and the API; loop run records (inline steps and a referenced Workflow); pipeline run loops and the padding fix. Each bug had a failing test first.
• UI: lanes, lane specs, progress, item labels, withLoops, loop edits and item validation (299 tests).
• On k3d with a controller from KubeVela master: an Application looping a group over three regions (records, run view, approving one pass with ?step=), the same keyed by name (passes rollout-us-east-*, labels in the record, key kept through sync), and a pipeline looping a step over three items all at once, on a workflow controller from workflow main.

Special notes for your reviewer

• Over 50 typed-in items warns rather than blocks: 50 is the controller's default --max-for-each-items, which a cluster can raise.
• The Expression source shows only in an application's studio; pipelines have no expressions.