+1 option #3 looks good On Wed, Aug 23, 2017 at 1:35 PM, Oleg Ostanin <oosta...@gridgain.com> wrote:
> Hello Igniters, I'd like to know which release option is preferred for the > community. I've done some research and some tests and I think the most > transparent way is option #3. > > On Wed, Aug 9, 2017 at 11:28 PM, Konstantin Boudnik <c...@apache.org> > wrote: > > > There's also #4: > > - providing an official environment, comprised of the toolchain, > > compilers, libs, etc,. The same environment (read "a container") could > > be used by an individual developer, RM, and/or in CI system for > > builds, tests, etc. And then you can have #3 pretty much for free! > > > > We are doing this in Bigtop for a much more complex environment, set > > of components and supported OS. I am sure it would be easy to do in > > Ignite. > > -- > > With regards, > > Konstantin (Cos) Boudnik > > 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622 > > > > Disclaimer: Opinions expressed in this email are those of the author, > > and do not necessarily represent the views of any company the author > > might be affiliated with at the moment of writing. > > > > > > On Sun, Aug 6, 2017 at 5:37 AM, Oleg Ostanin <oosta...@gridgain.com> > > wrote: > > > Hi, > > > > > > I'd like to start a discussion about Apache Ignite release procedure. > > > > > > I'm working on ticket Ignite-5249 "The release build procedure should > be > > > placed on the CI/CD server and available to run for the release > > engineer." > > > > > > https://issues.apache.org/jira/browse/IGNITE-5249 > > > > > > Currently we have three options for release: > > > > > > 1. Release engineer can do all the necessary steps on his local > machine. > > It > > > will require installing tons of soft like maven, doxigen, candle and so > > on. > > > Also building .net part of the project will require access to Windows > OS. > > > Build steps will not be transparent for community. Environment will not > > be > > > the same for each release which can lead to the compatibility issues. > > > > > > 2. All the steps (including signing) can be done on the public > continuous > > > integration server. Environment will be the same for each release, all > > the > > > steps will be transparent for community, but it will require uploading > at > > > least one private gpg certificate on the server. This is the high > > security > > > risk and I'm mentioning this option only for the sake of completeness. > > > > > > 3. Building of the project can be performed on the public continuous > > > integration server and then artifacts can be downloaded on the local > > > machine and signed and deployed to the staging repository from that > local > > > machine by running maven commands. No sharing of any credentials and > > > certificates will be needed, environment will be the same for each > > release, > > > all the steps will be transparent for community, artifacts created on > the > > > CI server can be verified by check-sums after uploading to the > > repository. > > > > > > Please, let me know if you have any suggestion or any questions about > > > anything related. > > > -- Alexey Dmitriev, VP Engineering *GridGain Systems* www.gridgain.com
