spark-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcelo Vanzin (JIRA)" <>
Subject [jira] [Commented] (SPARK-26565) modify dev/create-release/ to let jenkins build packages w/o publishing
Date Mon, 07 Jan 2019 23:47:00 GMT


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 {{}}
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/ to let jenkins build packages w/o publishing
> ---------------------------------------------------------------------------------------
>                 Key: SPARK-26565
>                 URL:
>             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:
> []
> i propose to change dev/create-release/
> 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

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message