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 >
