@mxm
Sure we should. Unfortunately the scripts to not have any '--dry-run'
toggle. Implementing this seemed not too easy on first sight, as those
release scripts do assume committed outputs of their predecessors and are
not yet in the shape to be parameterised.
So here is what I did:
1. As I did not wanted the scripts to do 'sudo' installs on my machine, I
first created a docker image with required prerequisites.
2. Cloned beam to that machine (to get the release.scripts)
3. Edited the places which seemed to call to the outside
- disabled any git push
- changed git url to point to some copy on local filesystem to pull
required changes from there
- changed './gradlew' build to './gradlew assemble' as build will not
work on docker anyway
- changed publish to publishToMavenLocal
- probably some more changes to ensure I do not write to remote
4. run the scripts
What I missed out:
1. There is some communication with svn (signing artefacts downloaded from
svn and committing). I just skipped those steps, as I was just too scared
to miss some commit and doing an accidental push to some remote system
(where I am hopefully not authorised anyway without doing proper
authentication)
If you believe I missed something which could be tested in advance, I d
happily do more testing to ensure a smooth release process.
michel
On Thu, Mar 14, 2019 at 11:23 AM Maximilian Michels <[email protected]> wrote:
> Hi Andrew,
>
> Sounds good. Thank you for being the release manager.
>
> @Michael Shall we perform some dry-run release testing for ensuring
> Gradle 5 compatibility?
>
> Thanks,
> Max
>
> On 14.03.19 00:28, Michael Luckey wrote:
> > Sounds good. Thanks for volunteering.
> >
> > Just as a side note: @aaltay had trouble releasing caused by the switch
> > to gradle5. Although that should be fixed now, you will be the first
> > using those changes in production. So if you encounter any issues. do
> > not hesitate to blame and contact me. Also I am currently looking into
> > some improvements to the process suggested by @kenn. So your feedback on
> > the current state would be greatly appreciated. I hope to get at least
> > https://issues.apache.org/jira/browse/BEAM-6798 done until then.
> >
> > Thanks again,
> >
> > michel
> >
> > On Wed, Mar 13, 2019 at 8:13 PM Ahmet Altay <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > Sounds great, thank you!
> >
> > On Wed, Mar 13, 2019 at 12:09 PM Andrew Pilloud <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > Hello Beam community!
> >
> > Beam 2.12 release branch cut date is March 27th according to the
> > release calendar [1]. I would like to volunteer myself to do
> > this release. I intend to cut the branch as planned on March
> > 27th and cherrypick fixes if needed.
> >
> > If you have releasing blocking issues for 2.12 please mark their
> > "Fix Version" as 2.12.0. Kenn created a 2.13.0 release in JIRA
> > in case you would like to move any non-blocking issues to that
> > version.
> >
> > Does this sound reasonable?
> >
> > Andrew
> >
> > [1]
> >
> https://calendar.google.com/calendar/embed?src=0p73sl034k80oob7seouanigd0%40group.calendar.google.com&ctz=America%2FLos_Angeles
> >
>
