On 11/03/2012 10:29 AM, Ate Douma wrote:
Hi Jasha,
On 11/02/2012 07:57 PM, Jasha Joachimsthal wrote:
Currently the person who executes the release process builds the release
artifacts on his own system. I wondered why we don't make the Maven release
from Jenkins. Jenkins has a plugin to perform Maven releases [1]. We no
longer depend on the environment settings of individual committers and our
"local" repository does not contain home brew artifacts from other
projects. Besides why would you do something manually if the machine can do
it for you ;)
[1] https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin
Nice idea :)
As a start, I wouldn't technically trust Jenkins to do releases for us: its just
broken itself way too often.
More important though, I think we might have a problem with the formal and legal
trust as well. The PMC, as representative for the ASF, is responsible for a
(signed) release as provided by a release manager.
IANAL, but making Jenkins the release manager and have the artifacts 'auto
signed by a machine, probably doesn't provide the proper 'trust' from a legal
POV.
It just occurred to me the above might sound a bit weird if you just read my
earlier feedback concerning the locally build and bundled wookie jar in the 0.17
binaries (see 0.17 release candidate DISCUSS thread).
My response above primarily concerns the fact we *also* build the sources
tarball during the same release step. And that artifact is the main concern from
a legal release POV. If the Release Manager would build only the sources tarball
locally, sign it personally, and let Jenkins (only) build the other artifacts,
it *might* legally be fine for the ASF.
Even then though, I doubt relying on Jenkins for this purpose is desirable.
It also would require Apache Repository (Nexus) to accept *release* (target)
deployments from a Jenkins (machine user) build. AFAIK it currently only allows
this for SNAPSHOT deployments.
Ate
Jasha
