You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by Maximilian Michels <mx...@apache.org> on 2016/03/08 15:22:48 UTC
Travis for pull requests
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
Re: Travis for pull requests
Posted by Amit Sela <am...@gmail.com>.
+1 on Travis for pull requests.
This is how Cloudera's spark-dataflow repo works and it was very convenient
for me as a contributor.
On Tue, Mar 8, 2016 at 4:23 PM Maximilian Michels <mx...@apache.org> 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
>
Re: Travis for pull requests
Posted by Davor Bonaci <da...@google.com.INVALID>.
For reference, INFRA-11414 tracks this [1].
[1] https://issues.apache.org/jira/browse/INFRA-11414
On Tue, Mar 8, 2016 at 9:35 AM, Davor Bonaci <da...@google.com> 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é <jb...@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é
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
Re: Travis for pull requests
Posted by Kostas Kloudas <k....@data-artisans.com>.
That is great news!
Thanks Davor!
> On Mar 10, 2016, at 10:20 AM, Amit Sela <am...@gmail.com> wrote:
>
> Thanks Davor!
>
> On Thu, Mar 10, 2016, 11:15 Maximilian Michels <mx...@apache.org> wrote:
>
>> 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é <jb...@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é <jb...@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é <
>> jb@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
>>>>>>>>> <davor@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é
>>>>>>>>>> <jb@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é
>>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>
>>>>>>>> Jean-Baptiste Onofré
>>>>>>>> jbonofre@apache.org
>>>>>>>> http://blog.nanthrax.net
>>>>>>>> Talend - http://www.talend.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Jean-Baptiste Onofré
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>
Re: Travis for pull requests
Posted by Amit Sela <am...@gmail.com>.
Thanks Davor!
On Thu, Mar 10, 2016, 11:15 Maximilian Michels <mx...@apache.org> wrote:
> 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é <jb...@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é <jb...@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é <
> jb@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
> >>>>>>> <davor@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é
> >>>>>>>> <jb@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é
> >>>>>>>>> jbonofre@apache.org
> >>>>>>>>> http://blog.nanthrax.net
> >>>>>>>>> Talend - http://www.talend.com
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>
> >>>>>> Jean-Baptiste Onofré
> >>>>>> jbonofre@apache.org
> >>>>>> http://blog.nanthrax.net
> >>>>>> Talend - http://www.talend.com
> >>>>>>
> >>>>>>
> >>>>>
> >>>> --
> >>>> Jean-Baptiste Onofré
> >>>> jbonofre@apache.org
> >>>> http://blog.nanthrax.net
> >>>> Talend - http://www.talend.com
> >>>>
> >>>
> >>>
> >>
> >
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
>
Re: Travis for pull requests
Posted by Maximilian Michels <mx...@apache.org>.
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é <jb...@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é <jb...@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é <jb...@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
>>>>>>> <davor@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é
>>>>>>>> <jb@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é
>>>>>>>>> jbonofre@apache.org
>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>
>>>>>> Jean-Baptiste Onofré
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>>
>>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>>
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Travis for pull requests
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é <jb...@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é <jb...@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 <davor@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é <jb@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é
>>>>>>>> jbonofre@apache.org
>>>>>>>> http://blog.nanthrax.net
>>>>>>>> Talend - http://www.talend.com
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>> Jean-Baptiste Onofré
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Travis for pull requests
Posted by Davor Bonaci <da...@google.com.INVALID>.
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é <jb...@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é <jb...@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 <davor@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é <jb@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é
>>>>>>> jbonofre@apache.org
>>>>>>> http://blog.nanthrax.net
>>>>>>> Talend - http://www.talend.com
>>>>>>>
>>>>>>>
>>>>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
Re: Travis for pull requests
Posted by Davor Bonaci <da...@google.com.INVALID>.
Sounds like we are all in agreement. Great!
On Wed, Mar 9, 2016 at 8:49 AM, Jean-Baptiste Onofré <jb...@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é <jb...@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é <jb...@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é
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>>
>>>>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Travis for pull requests
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é <jb...@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é <jb...@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é
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Travis for pull requests
Posted by Davor Bonaci <da...@google.com.INVALID>.
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é <jb...@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é <jb...@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é
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Travis for pull requests
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é <jb...@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é
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Travis for pull requests
Posted by Maximilian Michels <mx...@apache.org>.
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é <jb...@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é
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
Re: Travis for pull requests
Posted by Davor Bonaci <da...@google.com.INVALID>.
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é <jb...@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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Travis for pull requests
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com