I agree, and it's what I mean (assuming the signing is OK).
Basically, a release requires the following action:
- mvn release:prepare && mvn release:perform (with pgp signing, etc): it
can be done by Jenkins, BUT it requires some credentials in
.m2/settings.xml (for signing and upload on nexus), etc. In lot of
Apache projects, you have some guys dedicated for the releases, and a
release is simply an unique command line to execute (or a procedure to
follow)
- check the release content (human)
- close the staging repository on nexus (human)
- send the vote e-mail (human)
- once the vote passed:
-- promote the staging repo (human)
-- update Jira (human)
-- publish artifacts on dist.apache.org (human)
-- update reporter.apache.org (human)
-- send announcement e-mail on the mailing lists (human)
Regards
JB
On 03/09/2016 05:38 PM, Davor Bonaci wrote:
I think a release manager (a person) should be driving it, but his/her
actions can still be automated through Jenkins. For example, a Jenkins job
that release manager manually triggers is often better than a set of manual
command-line actions. Reasons: less error prone, repeatable, log of actions
is kept and is visible to everyone, etc.
On Wed, Mar 9, 2016 at 1:25 AM, Jean-Baptiste Onofré <[email protected]>
wrote:
Hi Max,
I agree to use Jenkins for snapshots, but I don't think it's a good idea
for release (it's better that a release manager does it IMHO).
Regards
JB
On 03/09/2016 10:12 AM, Maximilian Michels wrote:
I'm in favor of Travis too. We use it very extensively at Flink. It is
true that Jenkins can provide a much more sophisticated workflow.
However, its UI is outdated and it is not as nicely integrated with
GitHub. For outside contributions, IMHO Travis is the best CI system.
We might actually use Jenkins for releases or snapshot deployment.
Jenkins is very flexible and nicely integrated with the ASF
infrastructure which makes some things like providing credentials a
piece of cake.
Thanks for getting us started @Davor.
On Tue, Mar 8, 2016 at 6:35 PM, Davor Bonaci <[email protected]>
wrote:
We absolutely could -- that's why we forked over Dataflow's Travis
configuration to start with. With Max's recent fixes to the Flink runner,
this is very viable.
Travis vs. Jenkins is often a contentious discussion. Common arguments
against Travis are: scalability / capacity, hard to schedule periodic
runs,
and inability to automate the release process. There are many pros too;
e.g., automatic coverage on forked repositories.
We are generally in favor of doing this through Jenkins for the pull
requests, since that is our "official" CI. Many projects do this --
Apache
Thrift is one example [1]. Work on this is in-progress on our side.
Maintaining both systems is an extra burden, but I feel we'll end up
there
sooner or later. Thus, I'm also in favor of enabling the coverage that we
already have. Let's have both for now, and we can always adjust later.
I'll go ahead and file ticket(s) with INFRA.
[1] https://github.com/apache/thrift/pull/932
On Tue, Mar 8, 2016 at 6:31 AM, Jean-Baptiste Onofré <[email protected]>
wrote:
Hi Max,
+1 good idea !
Regards
JB
On 03/08/2016 03:22 PM, Maximilian Michels wrote:
Hi Beamers,
Quick suggestion: Could we enable Travis for the pull request of the
GitHub mirror? At the moment we only have Travis for our forks.
This would provide contributors with some feedback and also help us to
identify problems with the pull requests. I think we only need to tell
Infra to enable it for the apache/incubator-beam GitHub project.
Best,
Max
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
