imagej / tutorials

ImageJ2 programming examples
The Unlicense
179 stars 114 forks source link

Run nbconvert in travis and check for errors #53

Open kmader opened 6 years ago

kmader commented 6 years ago

Running jupyter nbconvert on all the notebooks and re-executing every line is a good way to check they are all valid and changes haven't broken them.

ctrueden commented 6 years ago

Dang it @kmader, I spent all day hacking on this. 😜 And it still doesn't work... 😞

The good news is: everything is in place for the SciJava travis-build.sh script to support validating Jupyter notebooks. And this repository (imagej/tutorials) is configured to take advantage of it. Any other repository wanting to check their notebooks need only model their Travis config after the one here. It is largely automatic, installing conda for you when you have an environment.yml, and running jupyter nbconvert --execute on each .ipynb file in the repo when the jupyter executable is available afterwards.

The bad news is twofold: 1) The source activate travis-scijava does not work, and various things I tried would not make it work; and 2) A couple of the notebooks here currently fail validation. And at least one (notebooks/3_-_Advanced_usage/2_-_Under_the_hood_-_ImgLib2.ipynb) has a bunch of errors that strangely do not trigger a non-zero exit code from nbconvert. Not sure what's up with that yet. I need to move on to other things for the moment, but at least the framework is here now.

kmader commented 6 years ago

Sorry I didn't mean to make so much work for you, but the travis-build script is quite well done. The non-zero exit code issue is unfortunately quite common but we got around it by grepping for traceback (https://github.com/kmader/Quantitative-Big-Imaging-2018/blob/master/circleci/execute.sh#L20) maybe that would work here as well (at least with the python kernels)

ctrueden commented 6 years ago

we got around it by grepping for traceback

Great idea. I'll do that in travis-build.sh next time I work on this issue. We can grep for both Python- and Java-style stack traces.

Any idea why source activate travis-scijava always says "source: not found" in the Travis output? (But it looks like you use CircleCI and not Travis?) I couldn't find others online reporting this problem. The source command is bash-specific, so I thought maybe Travis wasn't running the script in bash—I had #!/bin/sh at the top because I prefer to write POSIX-friendly scripts whenever possible—but when I explicitly changed it to #!/bin/bash it still fails with the same error. So I'm stumped.

ctrueden commented 5 years ago

With https://github.com/scijava/scijava-scripts/commit/6cd677cc012e8aa237b9476311c9a3ff6f14d087, I finally updated travis-build.sh to do things correctly. That is: conda's etc/profile.d/conda.sh gets sourced as needed for conda 4.4+. I believe the code is good now. However, there is still an issue:

travis-build.sh: 7: /home/travis/miniconda/envs/travis-scijava/etc/conda/activate.d/openjdk_activate.sh: [[: not found

It seems like Travis must not use bash; this is not the first time I've seen it barf on bash-specific syntax. Unfortunately, the double bracket syntax is part of the openjdk package's activation script. Maybe we can find a way to run the rest of the travis-build script with bash specifically, instead of whatever Travis is using (probably dash?).

ctrueden commented 5 years ago

This issue is blocked by the openjdk activation script not working on Travis. I made a fix that was supposed to address it (conda-forge/openjdk-feedstock#53) but after it was merged, it was pointed out that the fix is likely to be insufficient. I still have not had time to actually test it.

One way forward might be to have Travis run the conda stuff in a subshell with bash? Then we wouldn't have to make any more changes to the openjdk recipe upstream.

imagejan commented 4 years ago

@ctrueden wrote:

This issue is blocked by the openjdk activation script not working on Travis.

Is this still an issue? Maybe it can be fixed by replacing this in .travis.yml:

- script: ".travis/build.sh"
+ script: bash ".travis/build.sh"
imagejan commented 4 years ago

Maybe it can be fixed by replacing this in .travis.yml

Unfortunately no.

Neither script: bash ".travis/build.sh" (build #153) nor script: "bash .travis/build.sh" (build #154) changed anything in the build.