Set and document exit codes

[kwin]

To ease usage of the cli in non-interactive environments it would be good to set and document the process exit codes in case of failures for each command.
Currently always the default exit code (0 = SUCCESS) is used.

For that https://oclif.io/docs/commands#thiserrormessage-string--error-options-code-string-exit-number-ref-string-suggestions-string has to be used (e.g. in

aio-cli-plugin-cloudmanager/src/commands/cloudmanager/execution/get-step-details.js

Line 30 in 02527eb

this.error(error.message)

).

A mapping of the codes in https://github.com/adobe/aio-lib-cloudmanager/blob/1ec31d3234b97e09840864ed6eadaf7231e89914/src/SDKErrors.js#L51 and an exit code should be established.

[kwin]

Instead of catching the exceptions individually per command a catch method (https://oclif.io/docs/error_handling) can be implemented in base-*-command which

1. stops the spinner
2. emits an error message derived from the exception
3. returns an exit code derived from the exception

In most of the cases the thrown exceptions should be an instance of https://github.com/adobe/aio-lib-core-errors#aiocoresdkerror

[justinedelson]

See my comment in #224 -- I think there's a generalized issue here related to non-interactive use.

[kwin]

Actually calling Command.error with a string as first parameter uses the exit code 1 by default (https://github.com/oclif/errors/blob/95b0ea57bb23d0c4fcb0d877260418387e940492/src/handle.ts#L22). Would still be good to improve this, so that the exit code gets some more meaning (and you can derive the underlying exception from it).

[robrat]

Is there any progress in exit code handling? On Friday and today we have seen in our Github workflows that the aio cloudmanager commands do not work because the key expired, but this was returned as success to the pipeline:

$ aio cloudmanager:pipeline:update <id> --tag="v2.3.4"
updating pipeline... 400 - {"error_description":"Could not match JWT signature to any of the bindings","error":"invalid_token"}

$ echo $?
0

$ aio cloudmanager:pipeline:create-execution <id>
starting execution... 400 - {"error_description":"No valid bindings were found for organization and technical account combination","error":"invalid_token"}

$ echo $?
0

The Adobe IO CLI tools used in the Github workflow:

@adobe/aio-cli: 8.0.0
@adobe/aio-cli-plugin-cloudmanager: 2.4.3

[justinedelson]

hmm. I guess I misunderstood @kwin's last comment. I thought that the exit code would be 1 (although strangely in my testing it seems to be 2, not 1). But it appears that this is inconsistent because error is not used throughout -- in cases like these, action.start and action.stop are used and that exit code behavior is specific to error.

So I fear that what @kwin originally suggested is necessary -- extract the catch blocks from all of the commands and do it centrally.

[justinedelson]

Looking at the options available, I think it is achievable to set four distinct exit codes:

1 - A generic error has occurred
2 - A configuration error has occurred
3 - A validation error with the supplied flags or arguments has occurred
30 - An error emanating from the Cloud Manager SDK has occurred

While I understand the desire to have a unique exit code per error, I don't think that's practical, both due to internal API limitations and because it is not unimaginable that the Cloud Manager SDK could soon emit more than 255 unique error codes.

[github-actions]

🎉 This issue has been resolved in version 2.5.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀