fix(cli): Remove broken error handling

[danez]

data.state is not available when using Q.all() and only works with Q.allSettled().
As Q.all() is now used it does not make sense to do this check as the Promise
will be rejected immediately with an error if one of the calls to github fails.

This is broken since 7c1e4d9

Although I'm not super sure about this fix as I think the referenced commit might have broken more stuff, as Q.all() is not waiting for all promises to be fulfilled and instead cancels everything as soon as one fails, leaving the user in an undefined state which requests actually were send and which ones were canceled.
In contrast Q.allSettled() waits till everything is finished and you have to handle failures yourself with the state property.
Also the commit message of the change says that the user did not noticed that something failed which is wrong, as the state check was in place I guess. And it says it fixes #3 which seems unrelated.
So my ultimate solution would be to revert the commit in question but you need to decide :)

Fixes #46

https://github.com/kriskowal/q#combination

[hutson]

Thank you @danez for submitting this pull request.

Although I'm not super sure about this fix

Your change matches what we did with conventional-gitlab-releaser to fix the same bug over there. That change was just never ported to conventional-github-releaser.

So thank you for helping us, and the entire community, by submitting a fix to this project. 👍

I think the referenced commit might have broken more stuff, as Q.all() is not waiting for all promises to be fulfilled and instead cancels everything as soon as one fails, leaving the user in an undefined state

The previous behavior caused the CLI to return success if a single request to GitHub succeeded.

process.exit(1); was only called if every request to GitHub failed.

If one or more requests to GitHub failed your project/repository would be in an undefined state and you would not know that it was.

By failing on just a single request, we are raising the issue to the awareness of the project owner so that they can take the appropriate steps to correct the failure.

Though, in hindsight, we could have kept allSettled and just failed if a single request failed to return fullfilled as its state.

Also the commit message of the change says that the user did not noticed that something failed which is wrong, as the state check was in place I guess.

Yep, my understanding of what was happening was incorrect. As you noted, allSettled does distinguish between success and failure, just not in the way I've been familiar with (such as registering a success or failure handler).

And it says it fixes #3 which seems unrelated.

It's unrelated. Closing #3 was caused by cherry picking the commit from conventional-gitlab-releaser, where this change fixed issue number 3 over on that project.

[hutson]

Version v1.1.13 has been released.