Honestly, #3 and #4 look pretty similar for me. Considering that all the environment is already set for #3 I would go for it.
— Denis > On Aug 23, 2017, at 8:37 AM, Alexey Dmitriev <admitr...@gridgain.com> wrote: > > +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
