As an org admin, I want to lock a project so live workflows cannot be changed by a direct CLI push, so that every production change goes through a sandbox and review, matching the in-app lifecycle.
Part of #4852.
Status
Later, and blocked on a decision. The rule set must be written before build. Enforcement is expected to live mostly in the provisioner (Lightning side), not the CLI binary.
Problem
Today a developer with an API token can clone a project and push it straight to production through the provisioner, targeting the project UID directly, with no lifecycle awareness. There is no way to protect a project the way a protected branch protects main.
Rules to define (the deliverable)
- On a push to a project that contains a live workflow, what should the provisioner do: reject with a helpful error, create a new draft, update an existing draft, or error if there is no draft?
- A per-project protected flag (a GitHub protected-branch analog) that forces sandbox or draft editing when set.
- Sibling-workflow fate: when a single-workflow deploy targets a multi-workflow project, are untouched siblings left alone, forced to draft, or something else? (The current merge algorithm does not touch workflows you did not modify.)
- Whether the CLI gains a single-workflow deploy so the surface a developer can change is scoped to one workflow.
Acceptance criteria
- A written rule set for provisioner responses to CLI and deploy change requests under the draft/live model.
- A protected-project flag design.
Related
Pairs with carrying state in the wire format (#4897). Cross-repo: lightning (provisioner), kit (CLI).
As an org admin, I want to lock a project so live workflows cannot be changed by a direct CLI push, so that every production change goes through a sandbox and review, matching the in-app lifecycle.
Part of #4852.
Status
Later, and blocked on a decision. The rule set must be written before build. Enforcement is expected to live mostly in the provisioner (Lightning side), not the CLI binary.
Problem
Today a developer with an API token can clone a project and push it straight to production through the provisioner, targeting the project UID directly, with no lifecycle awareness. There is no way to protect a project the way a protected branch protects main.
Rules to define (the deliverable)
Acceptance criteria
Related
Pairs with carrying state in the wire format (#4897). Cross-repo: lightning (provisioner), kit (CLI).