Update validate-notebooks.yml

[neonWhiteout]

Removed cached dependencies

[neonWhiteout]

Took 47 min to run so might need to consider if we want this

[jpfairbanks]

I don't like a build that takes 47min to run. What was the point of eliminating the caching?

[neonWhiteout]

@jpfairbanks Using cached versions caused the notebook tests to fail. We could remove notebook tests altogether, or make smaller ones. @Saityi

[Saityi]

I think we may be seeing inconsistently failing builds when the cache is hit @jpfairbanks Specifically, IJulia seemingly fails to compile. I was encountering this issue a bit when first setting up the regression tests and thought I'd solved it.

40d0f9c5a0/cache.tzst -P -C /home/runner/work/StockFlow.jl/StockFlow.jl --use-compress-program unzstd
Cache restored successfully
Cache restored from key: Linux-test-julia-cache-83b2336a22a63ff57c0c2514ad1fd293f2b50aae8f35340d1b278652a2d186b7

[...]

ERROR: The following 1 direct dependency failed to precompile:

IJulia [7073ff75-c697-5162-941a-fcdaad2a7d2a]

Failed to precompile IJulia [7073ff75-c697-5162-941a-fcdaad2a7d2a] to "/home/runner/.julia/compiled/v1.9/IJulia/jl_m8mJqv".
ERROR: LoadError: ArgumentError: Path to conda environment is not valid: /home/runner/.julia/conda/3/x86_64

I've tried disabling the precompiling altogether, but that just punts the delay to another location because it compiles before running notebooks.

What we're trying to do is validate the notebook examples as part of CI to 1. detect regressions using real examples and 2. validate that the notebook examples -- which are important because we expect they'd useful to prospective users -- are always in working order. We've struggled to get the build both efficient and consistent, though. Caching improves efficiency, but leads to consistency issues, where the cached state is sometimes missing something it needs and we see stuff like the above or 'No such kernel named julia-1.9'; no caching is consistent, but takes an inordinate amount of time. I've hit the limit of my Julia & Jupyter Notebook knowledge, though, and I'm not sure how to move forward.

Options I was thinking about include:

• Spending more time hitting my head against the wall hoping I can figure out how to set up caching for Julia+Notebooks. I'm not sure at all what's missing here.
• Creating a more self-contained 'examples' module for CI which contains the notebook examples but runs in CI with standard dependencies for StockFlow.jl (no more IJulia issues)
  • This introduces a difficulty in keeping the two in sync, so I'm less inclined towards this option
• Creating a 'smoke test' module that hits all of the features used in the notebooks and papers, but isn't the actual examples or in a notebook
• Setting the notebook validation to only run before merges or on manual triggers
• Converting the notebooks examples to simple Julia files à la other AlgebraicJulia libraries I've seen like AlgberaicRewriting and generating docs from them.
  • I think we do want to keep interactive notebooks around, though.

I haven't had much time to dedicate to StockFlow.jl lately, so thinking about the above options is as far as I've gotten. Maybe you can provide some suggestions / thoughts?

[jpfairbanks]

I think another option is to convey the notebooks to Literate.jl examples or Docs pages and then use the standard AlgebraicJulia organization-level CI environments to build the docs. Then if the docs build, we know that the examples are working. How does that sound?

Oh wait, I reread your message and saw that as your last option, yes. This is what we should do. @quffaro has time to work on it.

[neonWhiteout]

Closed so we don't accidentally merge this