when hitting Ctrl+C in a 'docker run bob …', the main script itself actually can't be terminated by Ctrl+C, because it's PID 1
in that case, rather than just shutting down silently (by terminating itself using a SIGINT), we will see the subprocess exit (because Ctrl+C is sent to the whole process group)
When this happens, the return code of the process will be negative, to indicate that it didn't exit with that code, but instead got terminated by a signal of that (absolute) number
When receiving a signal, a process must kill itself using the same signal
sys.exit()ing 0, 1, 130, whatever will not signal to the calling program that we terminated in response to the signal
Best example: `for f in a b c; do bob deploy $f; done`, hitting Ctrl+C should interrupt Bob and stop the bash loop, but does not with `sys.exit()`:
# for x in php-7.3.13 php-7.3.13 php-7.3.13; do bob build $x; done
Fetching dependencies... found 1:
- libraries/libc-client-2007f
Building formula php-7.3.13 in /tmp/bob-35s7cr5z:
-----> Building php-7.3.13...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 18.7M 100 18.7M 0 0 7435k 0 0:00:02 0:00:02 --:--:-- 7434k
^Cool.
Fetching dependencies... found 1:
- libraries/libc-client-2007f
Building formula php-7.3.13 in /tmp/bob-vmuko2ra:
-----> Building php-7.3.13...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
20 18.7M 20 3887k 0 0 7479k 0 0:00:02 --:--:-- 0:00:02 7476k^Cool.
Fetching dependencies... found 1:
- libraries/libc-client-2007f
Building formula php-7.3.13 in /tmp/bob-p2t8as81:
-----> Building php-7.3.13...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
4 18.7M 4 943k 0 0 3599k 0 0:00:05 --:--:-- 0:00:05 3588k^Cool.
We want instead to have the loop end upon the first Ctrl+C.
That's only possible if Bash knows that we exited in response to Ctrl+C (=SIGINT), then it'll also terminate the loop
Bash will report the exit status as 128+$signal, so 130 for SIGINT, but sys.exit(130) does not to the same thing - the value of 130 is simply bash's representation
Killing ourselves with the signal number that we are aborting in response to does all this correctly, and bash will see the right WIFSIGNALED() status of our program, not WIFEXITED()
This brings Python 3 compatibility
With this change, all output from the formula ends up on stdout, without any buffering, meaning e.g. progress bars (from curl for instance) also finally show up in real time, without line buffering like before
In lieu of having a test suite, this at least ensures the setup.py
`console_scripts` entry is configured correctly, and that basic
CLI and arg functionality works.
This makes it easier to differentiate between the archives for
dependencies and that of the final build output by bob when sifting
through `/tmp/`. The archive type is now also apparent when reading
the console output.
Before:
```
Building formula foo in /tmp/bobrmyuSG:
...
Archiving.
/tmp/tmp4JUwdj
Deploying.
...
```
After (when combined with #28):
```
Building formula foo in /tmp/bob-rmyuSG:
...
Archiving.
Created: /tmp/bob-build-tmp4JUwdj.tar.gz
Deploying.
...
```
This means that the main bucket also benefits from the access denied
`anon=True` fall-back previously only used for the upstream bucket.
This helps with the case where AWS credentials are found, but are
for an account unrelated to either bucket.
Since the main bucket can now fall back to anonymous mode, a check
has been added to the deploy command to improve the UX.
Fixes:
https://github.com/kennethreitz/bob-builder/issues/26#issuecomment-301058112
An UPSTREAM_S3_BUCKET should usually allow "Everyone" for listing bucket contents.
If the S3 credentials for the normal bucket do not explicitly have access, a 403 will occur.
In that case, we re-try fetching the upstream bucket with anonymous authentication.
David Zuelke
kennethreitz