+1 to automating more, at least the creation and validation of release artifacts should all be completely automated. However signing should still be done by an individual--that's not something that (semantically) should be automated away.
As much as I am a fan of jupyter notebooks, I think the simplicity of these being flat text files has value. I would often be running these commands over an ssh terminal and having to start up a remote server and forward ports would be a pain (and a hassle even locally that might not be worth it). That being said, IMHO to continue to be readable such scripts should contain as little logic as possible, and be just a listing of commands. On Fri, Jan 10, 2020 at 9:44 AM Luke Cwik <[email protected]> wrote: > > I was always under the impression that artifact creation, signing and staging > for voting we always wanted to be "automated" in some way. I believe we could > have a jenkins job do this if we had a good way to transfer the release > managers signing keys to a Jenkins worker (via cloud key management system?). > So should we we should focus on better and more reliable release automation > instead of making the release scripts more interactive? > > On Fri, Jan 10, 2020 at 9:37 AM Udi Meiri <[email protected]> wrote: >> >> What does the community think about converting our release scripts to >> be Jupyter notebooks using bash_kernel? >> >> Since these scripts frequently fail (especially for first time releasers), >> we often need to rerun parts manually. The notebook format lets you do that. >> >> Certain steps require verification/inspection, such as before pushing >> commits. This is naturally done by spitting into multiple notebook cells. >> >> The notebook format also lends itself well to inline documentation and >> on-the-fly modification. >> >>
