enh: inherit non-zero exit code from traced program

[kaczmarj]

I am trying to add calls to reprozip trace within a continuous integration workflow, and I noticed that, currently, a failing reprozip trace returns exit code 0. This makes it difficult to check whether the commands being traced ran successfully. The proposed change exits reprozip trace with the same error code as the failing call.

Current behavior

$ reprozip trace cat fakefile.txt
cat: fakefile.txt: No such file or directory
[REPROZIP] 23:58:46.414 WARNING: Program exited with non-zero code 1
Configuration file written in .reprozip-trace/config.yml
Edit that file then run the packer -- use 'reprozip pack -h' for help

Uploading usage statistics is currently disabled
Please help us by providing anonymous usage statistics; you can enable this
by running:
    reprozip usage_report --enable
If you do not want to see this message again, you can run:
    reprozip usage_report --disable
Nothing will be uploaded before you opt in.
$ echo $?
0

Proposed behavior

$ reprozip trace cat fakefile.txt
cat: fakefile.txt: No such file or directory
[REPROZIP] 00:00:26.669 WARNING: Program exited with non-zero code 1
$ echo $?
1
$ cat fakefile.txt
cat: fakefile.txt: No such file or directory
$ echo $?
1

[remram44]

That makes a lot of sense 🤔 There should be a specific code for a ReproZip error during the trace.

[kaczmarj]

@remram44 - what would you like that code to be?

All failed tests are failing on a trace of I/O on a non-existing file:

subprocess.CalledProcessError: Command '['/home/travis/virtualenv/python3.3.6/bin/python', 
'-W', 'error:signal', b'/home/travis/build/ViDA-NYU/reprozip/reprozip/reprozip/main.py', 
'-v', '-v', '-v', 'trace', '--overwrite', '-d', 'readwrite-F-trace', './readwrite', 
'readwrite_test/non/existing/file']' returned non-zero exit status 1

This would be expected behavior with the proposed changes. I can update the tests.

[remram44]

My patch ended up being a bit larger, see #282. I use a different code for a ReproZip error during the trace (125).

I also had to avoid reporting those as ReproZip bugs.

I think this is a great idea, and while it's breaking compatibility, I don't think people should be relying on failing scripts returning 0 through ReproZip, so I'll include this in the next release.

[kaczmarj]

Closing in favor of #282