project:deploy:start exit codes

[mshanemc]

When project deploy start is run on a source tracked org (source:push) it fails with a non-zero exit code when there are no changes to deploy.

force:source:push doesn't throw an error when there are no changes to deploy, so this is different

What would you expect to happen for the same command if you provided a -m CustomObject or -d force-app/main/default/classes or -x package.xml and there was nothing to deploy? Do those still feel like 0 or should that be a 1?

And would you want the exit code to be different depending on the flags? (ex: the "no flags so do it like source:push" returns 0 but the flags that specify what to deploy would return 1 if they don't match something?

[ImJohnMDaniel]

Thanks @mshanemc for posting this question.

Personally, I am voting for "all deploys with no metadata should exit 0". I believe the output of “1” should be reserved for true “deployment failures”.

I have been working with the release candidate CLI that contains this command for the past week or so. I am already seeing various scenarios where I would have to change our approach on certain scripts. One of the most recent issues was with a new project team that we stood up this week. The project doesn’t yet have any metadata so the build script fails because when it does metadata push, there is nothing to push. A junior developer from that project was getting confused on how to access the scratch org if the script is failing. Granted, the scratch org itself did exist so it was as much a "newbie" issue of not knowing how to workaround the issue, but it is also an issue for how we standardize our projects as well. Of course, the problem is also that we can’t change our build scripts to discern between various types of command failures without enhancing the json output processing in our scripts; teaching it to ignore ignore this "false deployment failure" verses the real "true deployment failures", so we are left with a conundrum of sorts.

[ImJohnMDaniel]

@mshanemc -- One further thought with regards to option 3

• For the -x flag, I could see a warning. If I am correct that has been the behavior for years where metadata specified in a package.xml file is not present.
• For the -d flag, this should not produce an error or a warning. This is specifying a directory with random amount of metadata contents. If there is nothing in that folder currently, then don't worry about it. Maybe a info message statement stating that nothing was found to deploy would be appropriate.
• For the -m flag, this also should not produce an error or a warning. This is the same to me as the -d flag use case. You are specifying "whatever might be available in this directory or metadata type." Just because there is nothing there should not be cause for error or warning. Again, maybe an info message statement would be appropriate.

[seanhharrison]

Partial to option 3, voted option 1 but, regardless, not option 2 ("all exit 1")

[mshanemc]

why 1 and not 3?

[surajp]

@mshanemc Thanks for starting this discussion. I voted for 3, which I had also stated in my original issue description. I think it makes sense to return 1 when the user is explicitly the metadata that needs to be deploy (-d,-m,-x) and for push to return 0 since the objective of the push command is to deploy any pending changes from local to your source tracked org and even if there are no changes to deploy, the objective has been met

[justin-lyon]

Second this.

When we use the flags, we're expressing an expectation that something should exist at that position.

Which is different than without flags where we're most commonly just running it out of habit, like hitting Ctrl+S to save our work.

[jongpie]

@surajp and @justin-lyon you've both convinced me, I voted for option 3 as well 🥳 (I was originally going to vote for option 1)

[mshanemc]

option 3, shipped this week