[
https://issues.apache.org/jira/browse/HADOOP-12892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15204930#comment-15204930
]
Allen Wittenauer commented on HADOOP-12892:
-------------------------------------------
bq. Regarding the maven cache, is this at all addressed by the release builds
not being SNAPSHOT versions? All the precommit stuff should be SNAPSHOT, and I
doubt there are multiple RMs building the same non-SNAPSHOT release version.
I'll get to this in a second, but be aware there is still a process problem
here:
a) RM fires off a job on a shared machine to make a release
b) Someone submits a patch that changes hadoop's or some other project's build
such that it either mistakenly nukes the .m2 directory or maliciously changes
the contents of jars or other blackhat stuff to other running processes on the
Jenkins server
c) RM takes release artifacts, signs them (!) and then puts them up for vote,
completely unaware of what is actually in the package...
In other words, doing releases on the Jenkins slaves is an absolutely terrible
idea. Docker is not going to protect us here. (See also
http://www.apache.org/dev/release.html#owned-controlled-hardware, which means
if we're not breaking the letter of the law, we're definitely breaking the
spirit...)
Now that we've eliminated running this on jenkins for anything real, we're back
to RMs running this on their own boxes. RM who are much more likely to be
running things in parallel, even on the same branch....
> fix/rewrite create-release
> --------------------------
>
> Key: HADOOP-12892
> URL: https://issues.apache.org/jira/browse/HADOOP-12892
> Project: Hadoop Common
> Issue Type: Bug
> Components: build
> Reporter: Allen Wittenauer
> Assignee: Allen Wittenauer
> Attachments: HADOOP-12892.00.patch
>
>
> create-release needs some major surgery.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
