I think we need to balance where we are with where we want to be. There are a couple layers of abstraction that are all independently useful. We have to acknowledge that currently the steps in the guide and scripts don't quite match and also are not quite right, and that things go wrong and change. So I would suggest layering the functionality and keeping it working at all layers, never treating the topmost layer as a black box.
1. simple readable commands to perform the release, like Robert said 2. scripts that can be targeted at a git commit in the current checkout, like usual context-sensitive git commands 3. scripts that do the checking out for you, like the current scripts, operating on tags or commit hashes specified, context-insensitive I think useful properties of the layers are: - use git in normal ways (don't do the maven/gradle release plugin thing of committing then reverting) - each step should be be non-interactive (take parameters, don't ask interactive questions) - have a dry run mode - be idempotent (implied: clean up completely; use temp dirs; etc) - make changes to the release branch and master through PRs whenever possible; avoid blind pushes Kenn On Fri, Jan 10, 2020 at 10:09 AM Robert Bradshaw <[email protected]> wrote: > +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. > >> > >> >
