[ 
https://issues.apache.org/jira/browse/HBASE-21935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16789838#comment-16789838
 ] 

stack commented on HBASE-21935:
-------------------------------

Updated the patch to latest. Has set +x for the moment while still playing. 
Here is how I run it currently... doing just the build step w/o doing any 
commits:

{code}
./do-release-docker.sh -d ~/Downloads/rm -n -s build
{code}

You get asked a few questions. I answer branch-2.0... It'll volunteer 2.0.5. 
When asked what RC #, I say '1' (there is already a tag for 2.0.5RC1... thats 
what you'll build -- it'll ask you confirm that you want to build against the 
2.0.5RC1 existing tag). It'll ask gpg key to use ... then away it goes. It 
makes an output dir and in the output dir spews log to build.log.

FYI [~busbey]

> Replace make_rc.sh with customized spark/dev/create-release
> -----------------------------------------------------------
>
>                 Key: HBASE-21935
>                 URL: https://issues.apache.org/jira/browse/HBASE-21935
>             Project: HBase
>          Issue Type: Task
>          Components: rm
>            Reporter: stack
>            Assignee: stack
>            Priority: Minor
>              Labels: rm
>         Attachments: HBASE-21935.branch-2.0.001.patch, 
> HBASE-21935.branch-2.0.002.patch, HBASE-21935.branch-2.0.003.patch, 
> HBASE-21935.branch-2.0.004.patch, HBASE-21935.branch-2.0.005.patch, 
> HBASE-21935.branch-2.1.001.patch, HBASE-21935.branch-2.1.002.patch, 
> HBASE-21935.branch-2.1.003.patch, HBASE-21935.branch-2.1.004.patch, 
> HBASE-21935.branch-2.1.005.patch, HBASE-21935.branch-2.1.006.patch, 
> HBASE-21935.branch-2.1.007.patch
>
>
> The spark/dev/create-release is more comprehensive than our hokey make_rc.sh 
> script. It codifies the bulk of the RM process from tagging, version-setting, 
> building, signing, and pushing. It does it in a container so environment is 
> same each time. It has a bunch of spark-specifics as is -- naturally -- but 
> should be possible to pull it around to suit hbase RM'ing. It'd save a bunch 
> of time and would allow us to get to a place where RM'ing is canned, 
> evolvable, and consistent.
> I've been hacking on the tooling before the filing of this JIRA and was 
> polluting branch-2.0 w/ tagging and reverts. Let me make a branch named for 
> this JIRA to play with (There is a dry-run flag but it too needs work...).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to