[patch] optionally pass kernel to papermill (headless notebook execution)

[mbruns91]

This a quick way to ensure that an existing kernel is used by papermill, ignoring whatever kernelspec is given as metadata in the .ipynb file.

One could make the kernel specification an optional input (with python3 being the default), but I think to effectively make use of that, a lot of adaptations were required and I don't really see the benefit.

[liamhuber]

Brilliant. I like the change.

I am fine with this being the new default behaviour, but in order to guarantee that it is backwards compatible enough to qualify for just a minor bump, please

• Make the kernel variable in the .sh script (can default to the currently hard-coded value)
• Expose it as input in the notebooks action (kernel?)
• Expose it as input in the push-pull workflow (notebooks-kernel?)

[mbruns91]

Brilliant. I like the change.

I am fine with this being the new default behaviour, but in order to guarantee that it is backwards compatible enough to qualify for just a minor bump, please

• Make the kernel variable in the .sh script (can default to the currently hard-coded value)
• Expose it as input in the notebooks action (kernel?)
• Expose it as input in the push-pull workflow (notebooks-kernel?)

Did that. Note that now in all 3 places (.support/build_notebooks.sh, build-notebooks/action.yml and .github/workflows/push-pull.yml) the kernel defaults to python3.

[mbruns91]

BTW, I request here to merge into v3.3.0, which is maybe wrong if I understand correctly.
I should merge into main, and then a release v3.3.1 is generated from there, creating respective branch etc., right?

[liamhuber]

Nice!

Yes, it should target main. The steps now are:

• Run .support/update_actions_tag.sh main to re-target main
• Merge to main
• Checkout a new branch from main v3.3.1
  • (I'll update the title here to "patch" accordingly, IMO this is subtle enough to qualify)
• Run .support/update_actions_tag.sh to target the branch
• Push to remote (but don't open a PR!)
• Go to releases and make a new release actions-3.3.1
  • Set the release to target the branch v3.3.1
  • Manually set the previous release as actions-3.3.0
  • Generate release notes and hit release as usual

This release cycle is a little annoying, but I haven't worked out anything better that ensures that versions always internally reference their own version.

[mbruns91]

Alright, I hope I did it all correctly. Thanks for your instructions 👍

[liamhuber]

Alright, I hope I did it all correctly. Thanks for your instructions 👍

@mbruns91 yeah, super! Nice deployment 🚀 The only thing that was off was your new release wasn't tagged as "latest", but that was a super easy edit on the release page.

TBH I'm still not 100% satisfied with the process -- e.g. the releases internally target the branch they are released from (which is mutable and thus a security risk) instead of the actual tag we create (which is immutable and therefore verifiable as safe), but it's just so darned tricky given that the actions internally target other actions in the same repo. So I'm open to suggestions for improvement. That's future stuff though, you executed the existing release flow great!