I’ll take the shell scripts that I’ve been using and enrich them a little, and then I’ll share them with folks.I think we can likely put them in one of the plugins so that folks can simply run the script to move and download all the artifacts in their checkout of the svn directory.
Cheers, -Rob > On Jul 13, 2020, at 8:12 AM, Rob Tompkins <chtom...@gmail.com> wrote: > > Yes…I agree with that need. I was wondering if the release plugin was doing > that or nexus itself was doing that. But, I definitely understand that they > show up in nexus when using the plugin. > > Cheers, > -Rob > >> On Jul 13, 2020, at 8:10 AM, Gary Gregory <garydgreg...@gmail.com> wrote: >> >> Rob, if you plan on working on the release plugin, can you see if there is >> a way to have the VOTE not generate checksum lines for ASC files? IIRC we >> do not need checksums for ASC files. >> >> Speaking for corrupted uploads, does the Maven deploy goal check that its >> uploads are sane? >> >> Gary >> >> Gary >> >> On Mon, Jul 13, 2020, 08:04 Rob Tompkins <chtom...@gmail.com> wrote: >> >>> This all makes sense to me. Many thanks for the feedback here. >>> >>> Cheers, >>> -Rob >>> >>>> On Jul 13, 2020, at 5:12 AM, Mark Thomas <ma...@apache.org> wrote: >>>> >>>> On 13/07/2020 06:43, Stefan Bodewig wrote: >>>>> On 2020-07-12, Rob Tompkins wrote: >>>>> >>>>>> given the consistency of the signatures from the plugins…do we need to >>>>>> check them for releases anymore? >>>>> >>>>> Yes, please. Not everybody uses the plugins and even if everybody did a >>>>> misconfiguration could be pulling in the wrong key or a key not >>>>> available from the expected download location. >>>> >>>> +1, for several reasons >>>> >>>> It also catches corrupted uploads. >>>> >>>> It is simpler to fix during a release vote than after a release where >>>> we'd have to at least consider the possibility of malicious activity and >>>> respond accordingly until we could prove it wasn't. >>>> >>>> Mark >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
