Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fail hard on first error in batch script #177

Merged
merged 1 commit into from
Jul 23, 2020
Merged

Fail hard on first error in batch script #177

merged 1 commit into from
Jul 23, 2020

Conversation

yuvipanda
Copy link
Contributor

Bash generally keeps executing code line by line even
if any of the lines fail. For example, if your path is
not set properly, batchspawner-singleuser will not
be found by which. This should terminate execution.
However, without set -e, execution will just continue
and fail with a different error.

This patch does set -euo pipefail for all submission
scripts. This causes them to fail on:

  1. Any non-zero command return code (-e)
  2. On undefined environment variables (-u)
  3. Treat failures in any part of a pipeline as failure,
    rather than just the last command (-o pipefail)

Bash generally keeps executing code line by line even
if any of the lines fail. For example, if your path is
not set properly, `batchspawner-singleuser` will not
be found by `which`. This should terminate execution.
However, without `set -e`, execution will just continue
and fail with a different error.

This patch does `set -euo pipefail` for all submission
scripts. This causes them to fail on:

1. Any non-zero command return code (-e)
2. On undefined environment variables (-u)
3. Treat failures in any part of a pipeline as failure,
   rather than just the last command (-o pipefail)
@rkdarst
Copy link
Contributor

rkdarst commented Jun 30, 2020

This is a good idea, and probably should have been done before. Could you add a note to the changelog as a potentially breaking change? At least in my prologue, I run stuff for debugging that is expected to fail (echoing environment variables), and I wouldn't be surprised if others do, too. (I can also add the note myself).

It could be set in the default prologue, so that the minimum amount is hardcoded (of course, if someone wants it off then they can disable in their own prologue. Maybe it's better to have someone explicitely disable, than risk turning it off. I'd recommend to leave it as is.)

Thanks!

This was referenced Jul 23, 2020
@mbmilligan
Copy link
Member

Agree, this seems like a sensible change. Likewise agree with the reasoning about putting it in the base templates rather than the prologue.

@mbmilligan mbmilligan merged commit c439004 into jupyterhub:master Jul 23, 2020
@welcome
Copy link

welcome bot commented Jul 23, 2020

Congrats on your first merged pull request in this project! 🎉
congrats
Thank you for contributing, we are very proud of you! ❤️

mbmilligan added a commit that referenced this pull request Jul 23, 2020
@rkdarst
Copy link
Contributor

rkdarst commented Jul 29, 2020

I just realized an issue here, some of the scripts use /bin/sh, and it seems -o pipefail is a bashism. At least on my Ubuntu it is.

@rkdarst rkdarst mentioned this pull request Jul 29, 2020
rkdarst added a commit to rkdarst/batchspawner that referenced this pull request Aug 5, 2020
- `-o pipefail` is a bashism, so that the spawner scripts that use
  `/bin/sh` can't possibly work if it's not linked to bash.  As a
  immediate workaround, remove the option on the non-bash scripts.  A
  long-term plan will come later.
- Closes: jupyterhub#184, Discussion: jupyterhub#184
- Fixes up: jupyterhub#177
- Follow-up in: jupyterhub#188
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants