Please provide a switch to enforce pushing when doing a deployment and avoid catastrophic accidents!

[eltoroit]

Is your feature request related to a problem? Please describe.
A lack of a switch to enforce pushing when doing a deployment could cause catastrophic accidents, like deploying something to a production environment instead of a scratch org or push-enabled sandbox.

What are you trying to do
I am trying to push metadata to a scratch org or Source Tracked sandbox, but the command sf project deploy start is exactly the same command used to do a deployment to production. I want to avoid accidentally deploying to a production environment, considering the CLI instruction is exactly the same.

Describe the solution you'd like
Create a switch on the sf project deploy start --enforce-source-tracked to enforce a push (or any alternative method), and it should fail if the org is not Source Tracked enabled.

Describe alternatives you've considered
I have a build task in VS Code to do the deployments to scratch org, and I recently changed it to sf project deploy start, I am going to be reverting this back to sfdx force source push --forceoverwrite --json because that errors out if the org is not Source Tracked.

Additional context
Yesterday I was working on a project and I needed some metadata to be included in my scratch org, so I connected to the production environment and retrieved it. Once it was retrieved I needed it to be pushed to my scratch org but I executed a sf project deploy start command without switching back to the scratch org first. Fortunately, the deployment failed because otherwise, I would be making those changes in production!

[github-actions[bot]]

Thank you for filing this feature request. We appreciate your feedback and will review the feature at our next grooming or sprint planning session. We prioritize feature requests with more upvotes and comments.

[git2gus[bot]]

This issue has been linked to a new work item: W-13562616

[cristiand391]

@eltoroit do you have production orgs set as default targets for the CLI? or did this happen by accidentally rerunning a previous command from your shell history that included the prod username?

[eltoroit]

I manually switched to a production org, and I forgot to switch back. I went into production to retrieve some existing metadata that I needed in my scratch org, then I did a push to deploy that metadata to the scratch org, but I had forgotten to switch back (manually) to the scratch org. I had done this before, but because the commands were specific to a push it would fail with an error saying that you can't push to a production environment. We lost these guardrails by unifying the deploy commands.

[cristiand391]

Gotcha.
I was trying to understand where do you switch orgs (CLI checks --target-org flag -> local config -> global config).

We have a feature request that's related to the underlying problem: #1296

Would it help if the CLI could allow to set an org as a "sensitive" environment and then warn and prompt for confirmation before doing any destructive action?

[eltoroit]

YES, IT TOTALLY WOULD!

I just read the other feature request and I like it! Someway to prevent accidentally doing something stupid.