-
Notifications
You must be signed in to change notification settings - Fork 207
[MRG] Exitcodes #97
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
[MRG] Exitcodes #97
Conversation
More of a design question. Now that there is non-zero exit code on example building, does it still make sense to have a non-building example in the gallery, which is build then by travis and will always fail? |
More of a design question. Now that there is non-zero exit code on
example building, does it still make sense to have a non-building
example in the gallery, which is build then by travis and will always
fail?
I think that it is a question left to the user of whether to fail or not
the build.
|
Travis is unhappy for the Mayavi test case. I can't figure out why it does not work, I had solved that problem with the pyface forced update. And If I redo in a clean virtual environment it works, somehow in travis pyface does not get updated |
} | ||
|
||
Here you list the examples you allow to fail during the build process, | ||
keep in mind to specify the full relavite path from your `conf.py` to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
relavite -> relative
@Titan-C still need a rebase. |
67f7f80
to
d1aff53
Compare
@lesteve Now is working |
|
||
It might be the case that you want to keep the gallery even with | ||
failed examples. Thus you can configure Sphinx-Gallery to allow | ||
certain examples to fail and not to trow a failed build exit code 1 if |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
throw
for fail_example in still_ex_fails: | ||
expected_fail_msg.append(fail_example + ' failed leaving traceback:\n' + | ||
gallery_conf['failing_examples'][fail_example] + '\n') | ||
warnings.warn("\n".join(expected_fail_msg)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would use a print statement rather than a warning ... The warning adds some not really necessary information:
/home/le243287/dev/sphinx-gallery/sphinx_gallery/gen_gallery.py:171: UserWarning: Known failing examples, still failing:
../examples/plot_raise.py failed leaving traceback:
Traceback (most recent call last):
File "/home/le243287/dev/sphinx-gallery/sphinx_gallery/gen_rst.py", line 497, in execute_script
exec(code_block, example_globals)
File "<string>", line 2, in <module>
NameError: name 'iae' is not defined
warnings.warn("\n".join(expected_fail_msg))
@@ -56,4 +56,7 @@ script: | |||
- if [ "$DISTRIB" == "ubuntu" ]; then python setup.py nosetests; fi | |||
- if [ "$DISTRIB" == "conda" ]; then nosetests; fi | |||
- cd doc | |||
# Test a fast run of no-plot |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comments are switched ... To be honest the kind of comments that I don't find particularly useful.
"""Collects the list of falling examples during build and prints them with the traceback | ||
|
||
Raises ValueError if there where failing examples | ||
""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Align the triple quotes to the ones above.
Stop using multiple variables or the script example globals which should remain the globals namespace of the running example
More explicit message for examples not failing anymore
LGTM, great stuff, merging! Small remark, for next time try to keep different things in separate PRs (I know it is not that easy sometimes especially when there is a lot of code refactoring as in this PR). Still, it is a pity that it took such a long time getting this merged in. I reckon part of the reasons is that this PR was doing a lot of different things which makes it quite burdensome to review: exit code, thumbnail tweak when there is a n errror, md5 improvements, etc ... |
Small remark, for next time try to keep different things in separate PRs (I know it is not that easy sometimes especially when there is a lot of code refactoring as in this PR). Still, it is a pity that it took such a long time getting this merged in. I reckon part of the reasons is that this PR was doing a lot of different things which makes it quite burdensome to review: exit code, thumbnail tweak when there is a n errror, md5 improvements, etc ...
I do try to separate things, but in this case fixes just stated
treading together and then it was impossible to disentangle.
|
Yeah I know, that was just a reminder for the future. In my experience, PRs that go many different directions take a lot of energy and time to review and it ends up being frustrating for both the PR author and reviewers. |
This expands the behavior towards failing examples.
Closes #88, as examples that fail are stopped from execution to avoid noise in output.
Closes #95. Failed examples are accumulated internally. At build finished they exit with 1.
Error messages are now in STDERR