I'm happy to announce that we now have both Travis and Jenkins set up in Beam.
Both systems are building our master branch. The most recent status is incorporated into the top-level README.md file. Clicking the badge will take you to the specific build results. Additionally, we have automatic coverage for each pull request, with results integrated into the GitHub pull request UI. Exciting! Low-level details: The systems aren't exactly equal. Travis will run on any branch, while Jenkins will run on master only. Travis will run multi-OS, multi-JDK version, while Jenkins does just one combination. Notifications to Travis are pushed, Jenkins periodically polls for changes. Flink tests may not be running in Jenkins right now -- we need to investigate why. On Wed, Mar 9, 2016 at 8:57 AM, Davor Bonaci <[email protected]> wrote: > Sounds like we are all in agreement. Great! > > On Wed, Mar 9, 2016 at 8:49 AM, Jean-Baptiste Onofré <[email protected]> > wrote: > >> 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 >> > >
