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. >
