Transit CI should deploy only from tagged builds on the main branch, not from feature branches. Which workflow concept applies?
Select an answer to reveal the explanation.
Short Explanation
Conditional deploys are the "open only when the main-line stamp is on the crate" rule—feature branches stay in the yard. Blind every-branch deploys and laptop scripts skip that gate.
Full Explanation
Conditional execution limits sensitive jobs to matching branch and tag rules so production deploys do not fire from arbitrary pushes. Transit CI should run the deploy job only for tagged builds on the main branch, keeping feature-branch work out of production. The correct concept works because tags on main represent intentional release candidates; conditions encode that policy in the workflow so automation cannot "helpfully" ship unfinished transit mobile or backend work from a side branch.
Deploying every push from every branch with no branch or tag conditions fails because feature and experiment branches become accidental production releases, violating change control for rider-facing systems. Disabling tags and deploying whichever laptop last ran a local script fails conceptually: laptop-driven releases bypass the CI record, approvals, and artifact provenance the municipal pipeline exists to provide. Forcing feature-branch deploys into production to validate unfinished work live fails because production is not a scratch environment—unfinished transit changes can break schedules, payments, or customer apps for real riders.
Exam caveat: conditions must match the team's tagging convention exactly (annotated tags vs lightweight, protected main vs renamed defaults); misconfigured filters can either block all deploys or allow the wrong refs. Operational check: push a feature branch and confirm deploy does not run; create a tag on main for a release candidate and confirm deploy runs only then; review the workflow condition expression in peer review whenever branch naming policies change.