ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Dmitriev <admitr...@gridgain.com>
Subject Re: release procedure
Date Wed, 23 Aug 2017 15:37:47 GMT
+1
option #3 looks good

On Wed, Aug 23, 2017 at 1:35 PM, Oleg Ostanin <oostanin@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 <cos@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 <oostanin@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message