Well done :) About the Flink tests in Jenkins: I wonder why they don't execute. Just had a look at the Jenkins job. They seem to run fine: https://builds.apache.org/job/beam_MavenVerify/35/org.apache.beam$flink-runner/console
On Thu, Mar 10, 2016 at 7:40 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Awesome ! Thanks Davor. > > Regards > JB > > > On 03/10/2016 01:10 AM, Davor Bonaci wrote: >> >> 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 <da...@google.com> wrote: >> >>> Sounds like we are all in agreement. Great! >>> >>> On Wed, Mar 9, 2016 at 8:49 AM, Jean-Baptiste Onofré <j...@nanthrax.net> >>> 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é <j...@nanthrax.net> >>>>> 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 >>>>>>> <da...@google.com.invalid >>>>>>>> >>>>>>>> >>>>>>> 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é >>>>>>>> <j...@nanthrax.net >>>>>>>>> >>>>>>>>> >>>>>>>> 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é >>>>>>>>> jbono...@apache.org >>>>>>>>> http://blog.nanthrax.net >>>>>>>>> Talend - http://www.talend.com >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>> >>>>>> Jean-Baptiste Onofré >>>>>> jbono...@apache.org >>>>>> http://blog.nanthrax.net >>>>>> Talend - http://www.talend.com >>>>>> >>>>>> >>>>> >>>> -- >>>> Jean-Baptiste Onofré >>>> jbono...@apache.org >>>> http://blog.nanthrax.net >>>> Talend - http://www.talend.com >>>> >>> >>> >> > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com
