VSM: Allow triggering a pipeline (with the in-view upstream revision) directly from its VSM card

Issue Type

• Feature proposal

Summary

In a Value Stream Map (VSM) view, pipeline cards have no control to trigger a run for the upstream revision currently displayed on the card. To trigger or re-trigger a downstream pipeline for the in-view revision, the user must leave the VSM, navigate back to the dashboard, locate the pipeline by name, open "Trigger with Options", and manually re-select the upstream material revision from the dropdown to keep the value stream consistent with the VSM they were just looking at.

The VSM is therefore useful as a report, but is missing the small affordance that would also make it useful as an operator surface.

Motivation / Use Case

A common operator workflow is propagating a single upstream revision across a wide fan-out of downstream pipelines (for example multi-region deployments, multi-cluster rollouts, parallel environment branches). The VSM is the natural view for this: it shows at a glance which downstream pipelines are ahead, behind, or missing for a given upstream revision.

When several downstream pipelines need a manual trigger to catch up to the same upstream revision, the current flow requires, per pipeline:

1. Leaving the VSM
2. Navigating to the dashboard
3. Locating the pipeline by name (slow on installations with many pipelines)
4. Opening "Trigger with Options"
5. Manually selecting the correct upstream material revision from a dropdown
6. Triggering

This is repeated N times, with the risk of accidentally selecting an inconsistent revision on one of them and drifting the value stream.

The friction is highest in exactly the situation where the VSM is most useful: when a card already shows

No instance of this pipeline has run for any of the direct upstream dependency revision.

The card is already telling the operator that a trigger is needed, and already knows which upstream revision is in scope — but there is no way to act on that without leaving the view.

Proposal

Add a trigger affordance (e.g. a "▶" icon) to each pipeline card in the VSM view. Activating it would schedule the pipeline for the revision currently displayed on that card — i.e. the same revision the VSM is already rendering against — without the user having to re-select materials by hand.

Mechanically, this could be implemented as a UI binding over the existing POST /api/pipelines/:name/schedule endpoint, with the upstream material revisions populated from the VSM context.

A minimum viable implementation could:

• Show the affordance only on cards where a trigger for the in-view revision would actually do something (e.g. the pipeline has not yet run for that upstream revision, or the user explicitly chose to re-run).
• Be hidden or disabled for users without operate permission on the pipeline.
• Confirm the action in a small modal showing which revision will be used, to preserve safety.

Alternatives

• Userscripts / browser extensions — operators can build a Tampermonkey-style script that injects a trigger button into each VSM card and calls the schedule API directly. This works, but it puts the burden on individual installations to maintain a UI patch that arguably belongs in the product, and it is invisible to anyone landing on the VSM without the script installed.
• Status quo (dashboard round-trip) — current behaviour. Functional, but at the cost of context loss and a non-trivial chance of selecting an inconsistent material revision when triggering manually.

Any other info

Related: #13274 — Enable Value Stream Map to refresh pipeline status automatically. Both issues argue, from different angles, that the VSM should be more dynamic. #13274 wants the view to stay current; this issue wants the view to be actionable. Together they describe a shift of the VSM from a static report toward an operator surface.

Out of scope for this proposal:

• Bulk-triggering multiple pipelines from the VSM in one action (a natural follow-up once single-card triggering exists).
• Any change to the semantics of the existing "Trigger with Options" flow on the dashboard.
• Any change to the underlying scheduling API.

Environment

This proposal is a UX enhancement applicable to all currently-supported GoCD versions with the VSM feature enabled. No environment-specific details apply.