release scripts as interactive notebooks?

[Udi Meiri <eh...@google.com>]

What does the community think about converting our release scripts
<https://github.com/apache/beam/tree/master/release/src/main/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.

Re: release scripts as interactive notebooks?

[Kenneth Knowles <ke...@apache.org>]

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 <ro...@google.com>
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 <lc...@google.com> 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 <eh...@google.com> 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.
> >>
> >>
>

Re: release scripts as interactive notebooks?

[Robert Bradshaw <ro...@google.com>]

+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 <lc...@google.com> 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 <eh...@google.com> 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.
>>
>>

Re: release scripts as interactive notebooks?

[Luke Cwik <lc...@google.com>]

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 <eh...@google.com> wrote:

> What does the community think about converting our release scripts
> <https://github.com/apache/beam/tree/master/release/src/main/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.
>
>
>