As a person responsible for a live workflow, I want a deploy from the CLI to appear in the workflow's history, so that the history is the whole record rather than most of it.
Part of #4852 (Sandbox DevX epic). Phase 2, builds on version recording (#4866).
Outcome
A deploy that changes a live workflow records a version, the same as going live, promoting and restoring do.
Four things can change what a live workflow is running. Three of them record a version. A deploy from the CLI goes in through the provisioner, can change the content and can change whether it is live, and records nothing. So the history looks complete and is not, which is worse than recording none at all: someone reading it concludes nothing changed on Tuesday, and something did.
Scope
- A version recorded when a deploy changes a live workflow.
- Attributed to whoever the deploy authenticated as, and marked as having come from a deploy rather than from the editor.
- The existing three routes keep behaving as they do.
Notes
Needs a decision on what a deploy that touches twenty workflows should produce. Twenty versions is honest and noisy; one shared record is quieter and does not fit the per-workflow history.
Related to the push rules still open in #4921 and #4922, since both are about what a deploy is allowed to do to a live workflow.
As a person responsible for a live workflow, I want a deploy from the CLI to appear in the workflow's history, so that the history is the whole record rather than most of it.
Part of #4852 (Sandbox DevX epic). Phase 2, builds on version recording (#4866).
Outcome
A deploy that changes a live workflow records a version, the same as going live, promoting and restoring do.
Four things can change what a live workflow is running. Three of them record a version. A deploy from the CLI goes in through the provisioner, can change the content and can change whether it is live, and records nothing. So the history looks complete and is not, which is worse than recording none at all: someone reading it concludes nothing changed on Tuesday, and something did.
Scope
Notes
Needs a decision on what a deploy that touches twenty workflows should produce. Twenty versions is honest and noisy; one shared record is quieter and does not fit the per-workflow history.
Related to the push rules still open in #4921 and #4922, since both are about what a deploy is allowed to do to a live workflow.