ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <...@apache.org>
Subject Re: release procedure
Date Wed, 09 Aug 2017 20:28:03 GMT
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
  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.

View raw message