Feature Request: A way to check for error on a command in orgInit.sh

[jrattanpal]

Currently, if we have an error in a command then, most often, it will continue to try and run other commands which may also fail. We don't want to whitelist repos to allow users to use bash commands to check for errors.

If there can be a mechanism to see if previous command has failed and gracefully exit out of our script (maybe with a message) then that'll go a long way.

I tried to use BYOO in one of our orgs. The very first commands failed because community is not setup yet it continued to try and run other commands.

http://hosted-scratch.herokuapp.com/byoo?template=https://github.com/forcedotcom/WorkDotCom-Partners&email=required

[mshanemc]

I agree that sucks. The counterargument:

sometimes things fail, and it's useful to be able to go into the org and debug why (bulk load jobs, permissions stuff, etc). Or you open it and do a failed step rather than delete and start over.

We could make a environment variable to let the deployer's owner control the behavior...it'd be that plus a little change in the lines/commonBuild stuff. Then you could decide what's the lesser evil.

The other approach would be to make fail=>bail the default behavior and add an optional parameter on the deploy request for &forcecontinue=true or something like that.

Thoughts? Happy to get a PR around this.

[jrattanpal]

@mshanemc

I think there is some confusion.

My previous experience was that if a command failed then execution will stop. But when I tried above, the script continued to run all the commands even though the first one failed.

I don't want it to continue on as you suggested with &forcecontinue=true. I want it to stop if a command fails. In almost all use cases we have, if a command fails then we want it to stop. Especially for BYOO where, for example, if a package install fails then we don't want to push the data as it will fail anyways

In addition, if there was a way to know about an error and display a custom message that could indicate possible issues then the user will know what to look for (even if it may not be that error but we can try and guess).