Implement working directory option for notebook execution

[mbruns91]

Summary

• Add an optional notebooks-working-directory input to build-notebooks.
• Forward the input to papermill via --cwd when set.
• Document how repositories can align CI notebook execution with local JupyterLab resource paths.

Testing

• Manually run .support/build_notebooks.sh with and without the fourth argument.
• Run actionlint to verify correct syntax and compatibility with current runners etc.
• Open a downstream PR and verify the new feature is indeed working.

Merging this PR closes #171.

[mbruns91]

Looking at courier/54, this feature seems to work as intended.

@liamhuber: with some positive reaction from you, I will merge this and make the new release. This time, I already used a release-tag formatted branch, so maybe the release will be successful on the first try.

[liamhuber]

Yeah, super, no objections from me, just one question: it looks very similar to the existing notebooks-dir -- is there a use case where the values should differ? I.e. could we avoid changing the action file and update the build_notebooks.sh to always create CWD_ARGS from ${NOTEBOOKS_DIR} instead? I assume this would have some bad side-effect sometimes, I'm just curious to learn what it is.

[mbruns91]

it looks very similar to the existing notebooks-dir -- is there a use case where the values should differ?

One could get a similar effect by making notebooks reference resources relative to notebooks-dir. In our repos, this will almost always be repo_root/notebooks/, so it should work. However, I think they should stay separate because notebooks-dir is a discovery root, while papermill --cwd changes the runtime working directory seen by the notebook kernel. Deriving --cwd from notebooks-dir would make the current default notebooks-dir: notebooks execute from notebooks/ instead of the repository root, which is a behavioral change and can break notebooks using repo-root-relative paths/imports/config. The new input is a bit niche, but it keeps the existing default unchanged while allowing repos that expect local JupyterLab-style execution from notebooks/ to opt in explicitly. A use-case I could think of is for example integration tests leveraging notebooks, but relying on different resources than used for the "demo-execution" supposed to be done by the user or that is used for auto-generating docs.