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

Marcelo Vanzin commented on SPARK-26565:
----------------------------------------

Stepping back a little, what is the purpose of that packaging build?

IIRC it was meant to publish an unofficial nightly "distribution" that people 
could download / use with a custom maven repo; and for that you need GPG keys.

If we remove the keys, is that build doing anything useful? If it is, can we 
just add that to the existing test scripts instead, and get rid of that build?

To answer one of the questions, the current "official" way to create a release 
is to run {{do-release-docker.sh}} from the master branch (regardless of which 
release you're creating); the web site may need some updates to reflect that.

> modify dev/create-release/release-build.sh to let jenkins build packages w/o 
> publishing
> ---------------------------------------------------------------------------------------
>
>                 Key: SPARK-26565
>                 URL: https://issues.apache.org/jira/browse/SPARK-26565
>             Project: Spark
>          Issue Type: Bug
>          Components: Build
>    Affects Versions: 2.2.3, 2.3.3, 2.4.1, 3.0.0
>            Reporter: shane knapp
>            Assignee: shane knapp
>            Priority: Major
>         Attachments: fine.png, no-idea.jpg
>
>
> about a year+ ago, we stopped publishing releases directly from jenkins...
> this means that the spark-\{branch}-packaging builds are failing due to gpg 
> signing failures, and i would like to update these builds to *just* perform 
> packaging.
> example:
> [https://amplab.cs.berkeley.edu/jenkins/view/Spark%20Packaging/job/spark-master-package/2183/console]
> i propose to change dev/create-release/release-build.sh...
> when the script is called w/the 'package' option, remove ALL of the following 
> bits:
> 1) gpg signing of the source tarball (lines 184-187)
> 2) gpg signing of the sparkR dist (lines 243-248)
> 3) gpg signing of the python dist (lines 256-261)
> 4) gpg signing of the regular binary dist (lines 264-271)
> 5) the svn push of the signed dists (lines 317-332)
>  
> another, and probably much better option, is to nuke the 
> spark-\{branch}-packaging builds and create new ones that just build things 
> w/o touching this incredible fragile shell scripting nightmare.



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

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

Reply via email to