activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: [DISCUSS] release process improvements
Date Fri, 15 Sep 2017 15:55:54 GMT
I tweaked the helper script to verify the downloaded tar/zip files
using their downloaded signature, then update the downloaded .md5 file
with filename info so it can verify easily with CLI tools, dropped
downloading the .sha1 and generated a new .sha512, and then at the end
verifies all the checksums as a sanity check (somewhat superfluous for
the SHA512, but doesn't hurt).

https://github.com/apache/activemq-artemis/commit/b7b2960e1f1870246f0c113f56d22cfc0f7a4269

If folks are happy with this I can update the instructions at
https://github.com/apache/activemq-artemis/blob/master/RELEASING.md to
reflect the slight process changes needed.

Robbie

On 14 September 2017 at 15:32, Clebert Suconic
<clebert.suconic@gmail.com> wrote:
> I thought about checking the sum. Didn't have time.
>
> I would check the files created by nexus Instead of creating new ones
> thought.
>
>
> Feel free to tweak the script.  I will be out for a week.  I will just
> finish the release and I will be away for a week.
>
> On Thu, Sep 14, 2017 at 5:48 AM Robbie Gemmell <robbie.gemmell@gmail.com>
> wrote:
>
>> Script looks good, though I'd tweak it a little to cover the eased
>> checksum verification and supplying a SHA512 one (more below).
>>
>> I agree that similar changes would be good for the ActiveMQ 5 releases
>> also, thats the main reason I didn't just detail things on the Artemis
>> 2.3.0 vote thread.
>>
>> Back to the script, I'd suggest tweaking it to add a check that the
>> signature verifies to ensure the downloaded files are ok, then rather
>> than download the .sha1 I'd have it generate a .sha512 file instead,
>> and would similarly update/regenerate the .md5 file to embed filename
>> info so it verifies easily with the CLI tooling. E.g:
>>
>>     gpg --verify $theFile.asc
>>     md5sum $theFile > $theFile.md5
>>     sha512sum $theFile > $theFile.sha512
>>
>> Then testers and end users downloading the checksum files can just
>> verify them with the -c flags on the CLI tools, e.g you can check all
>> the checksums with just:
>>     md5sum -c *.md5
>>     sha512sum -c *.sha512
>>
>> On 13 September 2017 at 23:36, Clebert Suconic
>> <clebert.suconic@gmail.com> wrote:
>> > Ok, fair enough... I can see this as a process improvement.
>> >
>> > I wasn't just understanding what you were proposing clearly enough.
>> >
>> > I just added this script here:
>> >
>> https://github.com/apache/activemq-artemis/blob/master/scripts/download-release.sh
>> >
>> >
>> > I didn't update the RELEASE.md yet...
>> >
>> >
>> > I would add that during the release, you use the download-release from
>> > the staged mvn repo using that script into the dev area.
>> > The vote would have the staged download on dev, and we just make a
>> > simple copy from one place to the other.. and remove the previous
>> > thing.
>> >
>> >
>> > But I think this should be also done on ActiveMQ 5 releases.
>> >
>> >
>> >
>> > The thing that threw me of was when you mentioned extra work.. there's
>> > no extra work here :)
>> > It's actually saving me from screwing up eventually, so I take it as
>> > an improvement.
>> >
>> >
>> > On Wed, Sep 13, 2017 at 1:19 PM, Robbie Gemmell
>> > <robbie.gemmell@gmail.com> wrote:
>> >> Yes, thats essentially what I mean and do, I have a txt file I keep
>> >> some comments in as notes, and can source as a script to download the
>> >> various tars and signatures from nexus (though it could equally pull
>> >> them from the maven local repo, verifying the Nexus ones is good I
>> >> think), verify the signature, and generate new MD5+SHA512 checksum
>> >> files that include the filename details (it could instead manipualte
>> >> the MD5 one rather than create new). I execute that in a directory
>> >> within a checkout of the dist dev, then commit the files after a
>> >> little validation and open the vote.
>> >>
>> >> The process of putting the files in the dist dev area is mostly the
>> >> same as what will be getting done now for the final release, it just
>> >> uses a different subtree of the same parent dist svn repo, so for
>> >> example you would use a subdir of
>> >> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/
>> >> before the vote rather than of
>> >> https://dist.apache.org/repos/dist/release/activemq/activemq-artemis/
>> >> after the vote.
>> >>
>> >> To complete the example, had the files for the recent Artemis 2.3.0
>> >> vote been in the dist dev area already you would just do something
>> >> like this to complete the release once the vote had passed:
>> >> svn cp -m "add files for activemq-artemis-2.3.0"
>> >>
>> https://dist.apache.org/repos/dist/dev/activemq/activemq-artemis/2.3.0-rc1
>> >>
>> https://dist.apache.org/repos/dist/release/activemq/activemq-artemis/2.3.0
>> >>
>> >> Robbie
>> >>
>> >> On 13 September 2017 at 17:52, Clebert Suconic
>> >> <clebert.suconic@gmail.com> wrote:
>> >>> I actually see how to make the copy into dev... let me play with it
a
>> >>> little bit....
>> >>>
>> >>> On Wed, Sep 13, 2017 at 12:44 PM, Clebert Suconic
>> >>> <clebert.suconic@gmail.com> wrote:
>> >>>> what about this:
>> >>>>
>> >>>> Currently mvn release and mvn upload will always send the release
to
>> nexus,
>> >>>>
>> >>>> So what about:
>> >>>>
>> >>>> - we provide an script to artemis to download the correct bits of
the
>> >>>> release, the release manager would use that script to perform such
>> >>>> download.
>> >>>> - The release manager would place it on the dev repository Robbie
is
>> >>>> mentioning... (that means.. we wouldn't really have an extra step).
>> >>>>
>> >>>>
>> >>>> On thing I'm not sure how to do is... how to upload it to the dev
dist
>> >>>> at https://dist.apache.org/repos/dist/dev/activemq/
>> >>>>
>> >>>> and how we would make the final move? just a regular copy?
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Wed, Sep 13, 2017 at 9:49 AM, Robbie Gemmell
>> >>>> <robbie.gemmell@gmail.com> wrote:
>> >>>>> On 13 September 2017 at 14:35, Clebert Suconic
>> >>>>> <clebert.suconic@gmail.com> wrote:
>> >>>>>> On Wed, Sep 13, 2017 at 9:21 AM Robbie Gemmell <
>> robbie.gemmell@gmail.com>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>>> This was less about time, though there is some benefit
in that
>> regard,
>> >>>>>>> with how much depending on how particular people actually
verify
>> the
>> >>>>>>> checksums I guess.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> Actually this is kind of moot. nexus does that check for
you.  You
>> cannot
>> >>>>>> upload a release with a checksum broken. It won't let you
close.
>> >>>>>>
>> >>>>>> Like. Last week I had to restart the release once because
MVN
>> upload broke
>> >>>>>> the checksum somewhere.
>> >>>>>> --
>> >>>>>> Clebert Suconic
>> >>>>>
>> >>>>> Whether the files in Nexus are ok isn't sufficient. The archives
and
>> >>>>> checksum files in the dist repo are the mirrorer official release
>> >>>>> artifacts (and strictly only the source ones at that), and Nexus
cant
>> >>>>> check those. There could be a problem deploying those bits for
a
>> >>>>> variety of reasons, so we check they are ok. Users downloading
the
>> >>>>> release archives also tend to grab the checksums from the dist
repo
>> >>>>> because that is their official source, in order to verify downloads
>> >>>>> that have come from the third party mirrors which dont store
the
>> >>>>> checksums for obvious reasons.
>> >>>>>
>> >>>>> Robbie
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Clebert Suconic
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Clebert Suconic
>> >
>> >
>> >
>> > --
>> > Clebert Suconic
>>
> --
> Clebert Suconic

Mime
View raw message