Improve error reporting

[dariusz-michura]

I run deployer as external process in my application.

1. I track process exit code value to find out whether deployment process succeeded or failed. The issue is that in case of any problem deployer always return 1 regardless of the real cause of the problem. Could the deployer return more descriptive values?
2. Currently error messages are reported to a console. Could they be reported to application error stream too?

[dariusz-michura]

I prepared a fork with changes I would like to introduce: #40.

[weierophinney]

We return a non-zero exit status. *nix systems use non-zero to indicate any failure, but those no real standardization on what different values mean. At most, we could add verbosity flags and logging based on those flags.

Currently error messages are reported to a console. Could they be reported to application error stream too?

IIRC, we write to STDERR whenever possible for error situations; if you can find places where we are not, please file separate issues and/or pull requests to fix them.

I prepared a fork with changes I would like to introduce.

Then please submit a pull request if you haven't already; if you have, link the two (by dropping a comment in this one referencing the pull request, or in the pull request referencing this issue).

[dariusz-michura]

We return a non-zero exit status. *nix systems use non-zero to indicate any failure, but those no real standardization on what different values mean. At most, we could add verbosity flags and logging based on those flags.

My problem was that I was running the deployer and I could not get the result file. The only information I had was exit code value 1 and empty error stream. I did not know what went wrong and why.

My first attempt was to define more exit codes for each problematic situation. Then I made use of deloyer output, instead of error, stream in my application to get know what went wrong. Finally I noticed that there was problem with running the composer. To investigate it I had to attach composer output to deployer error message. All those changes allowed me to find out that final package file was not created because of corrupted composer cache.

Currently I see that for my purposes single non-zero exit code would be enough but it must be supported by extensive information in output/error stream.

IIRC, we write to STDERR whenever possible for error situations; if you can find places where we are not, please file separate issues and/or pull requests to fix them.

I am not good at PHP but my impression is that you do not write anything to error stream.

Then please submit a pull request if you haven't already; if you have, link the two (by dropping a comment in this one referencing the pull request, or in the pull request referencing this issue).

I added link to my pull request to my comment above.
As I wrote above my fork contains all changes that helped me to investigate my problem. Currently I see that only one change is required: composer output attached to error message in case composer run fail.