Re: Tip for Running Unit Testing against Your Own Fork

[Naik Kaxil]

Let's add this info to 
https://github.com/apache/incubator-airflow/blob/master/dev/README.md . Can 
someone send a PR ??

On 22/11/2018, 09:52, "Jarek Potiuk"  wrote:

Seems that the dev list does not like attachments. The screenshot showing
the right setting is here:

https://drive.google.com/open?id=1-6_Fec0vLiKqEamCoY_xOh4Wb8tV-R37

J.


On Thu, Nov 22, 2018 at 10:49 AM Sai Phanindhra  wrote:

> Some admin has to check. I am not sure what options they will be seeing.
> They should have option to toggle auto cancel builds just like i had.
>
> On Thu, 22 Nov 2018 at 14:21, Jarek Potiuk 
> wrote:
>
> > There is - "auto cancellation" (see the screenshot). So maybe it's just 
a
> > matter of flipping the toggle by the admins?
> >
> > [image: Screenshot 2018-11-22 at 09.49.27 (1).png]
> >
> > J.
> >
> >
> >
> >
> > On Wed, Nov 21, 2018 at 6:19 PM Sai Phanindhra 
> > wrote:
> >
> >> Hi,
> >> I am not sure about that, there has to be a provision to stop multiple
> >> builds same PR irrespective user's access to repo. I think admins have
> to
> >> update settings of repo in travis.
> >> [image: Screenshot 2018-11-21 at 10.46.11 PM.png]
> >>
> >> On Wed, 21 Nov 2018 at 22:18, Deng Xiaodong 
> wrote:
> >>
> >>> Hi,
> >>>
> >>> I believe only the folks who have write access to the codebase, i.e.
> the
> >>> committers, can stop/cancel/re-run the Travis CI jobs.
> >>>
> >>> What the contributors can do is to make commits to the branch in their
> >>> own fork & ensure it’s working/passing tests as expected, before they
> >>> create the Pull Request.
> >>>
> >>>
> >>> XD
> >>>
> >>> > 

Kaxil Naik 

Data Reply
Nova South
160 Victoria Street, Westminster
London SW1E 5LB - UK 
phone: +44 (0)20 7730 6000
k.n...@reply.com
www.reply.com
On 22 Nov 2018, at 12:41 AM, Sai Phanindhra 
> >>> wrote:
> >>> >
> >>> > Deng Xiaodong thanks for helping us with this. I hope this will help
> >>> us in
> >>> > developing and testing fast. I would like to ask is there a 
provision
> >>> to
> >>> > cancel our own builds in travis. I can see sometimes contributors 
are
> >>> > pushing multiple commits in small intervals of time leading to
> multiple
> >>> > builds. If we can kill/cancel old builds and let only the latest
> build
> >>> run
> >>> > it would be better use of resources.
> >>> >
> >>> > On Wed, 21 Nov 2018 at 21:56, Deng Xiaodong 
> >>> wrote:
> >>> >
> >>> >> Hi folks,
> >>> >>
> >>> >> I noticed that testing is somehow a problem for some folks who 
would
> >>> like
> >>> >> to contribute (either have trouble setting local testing env, or
> >>> misused
> >>> >> Pull Request to test). Actually because Airflow is using Travis CI
> >>> for unit
> >>> >> testing, running testing for any of your change/commit is very very
> >>> easy.
> >>> >>
> >>> >> Steps
> >>> >> 1. Go to https://travis-ci.org/, click “Sign in with GitHub”. If
> you
> >>> >> haven’t done this before, possibly it will ask you to “Authorize
> >>> Travis CI
> >>> >> for Open Source”.
> >>> >> 2. After this is done, you may be redirected to
> >>> >> https://travis-ci.org/account/repositories. Then you will see a
> list
> >>> of
> >>> >> your public repositories. Let’s assume you have already forked
> >>> Airflow,
> >>> >> then just toggle it on.
> >>> >> 3. Everything is good to go! From now on, if you make any
> >>> change/commit to
> >>> >> your own fork of Airflow, the Travis CI test will be triggered
> >>> >> (Travis-related files is already included in the Airflow codebase).
> >>> >>
> >>> >> Why to do this
> >>> >> - You don’t have to set up local testing env, or misuse Pull 
Request
> >>> to
> >>> >> test your code change.
> >>> >> - Travis CI is free for Open Source project (public repo), but it
> only
> >>> >> allows 5 concurrent tests. On the other hand, Apache is using
> >>> >> paid-subscription (possibly for unlimited concurrent tests). So
> >>> mis-using
> >>> >> Pull Requests to test your change/commit will result in a slightly
> >>> bigger
> >>> >> bill that ASF receives.
> >>> >>
> >>> >> Hope this is somehow helpful for folks who would like to 
contribute.
> >>> >>
> >>> >> XD
> >>> >>
> >>> >
> >>> >
> >>> > --
> >>> > Sai Phanindhra,
> >>> > Ph: +91 9043258999
> >>>
> >>>
> >>
> >> --
> >> Sai Phanindhra,
> >> Ph: +91 9043258999
> >>
> >
> >
> > --
> >
> > Jarek Potiuk
> > Polidea  | Principal Software Engineer
> >
> > M: +48 660 796 129 <+48660796129>
> > E: 

Re: Tip for Running Unit Testing against Your Own Fork

[Jarek Potiuk]

Seems that the dev list does not like attachments. The screenshot showing
the right setting is here:

https://drive.google.com/open?id=1-6_Fec0vLiKqEamCoY_xOh4Wb8tV-R37

J.


On Thu, Nov 22, 2018 at 10:49 AM Sai Phanindhra  wrote:

> Some admin has to check. I am not sure what options they will be seeing.
> They should have option to toggle auto cancel builds just like i had.
>
> On Thu, 22 Nov 2018 at 14:21, Jarek Potiuk 
> wrote:
>
> > There is - "auto cancellation" (see the screenshot). So maybe it's just a
> > matter of flipping the toggle by the admins?
> >
> > [image: Screenshot 2018-11-22 at 09.49.27 (1).png]
> >
> > J.
> >
> >
> >
> >
> > On Wed, Nov 21, 2018 at 6:19 PM Sai Phanindhra 
> > wrote:
> >
> >> Hi,
> >> I am not sure about that, there has to be a provision to stop multiple
> >> builds same PR irrespective user's access to repo. I think admins have
> to
> >> update settings of repo in travis.
> >> [image: Screenshot 2018-11-21 at 10.46.11 PM.png]
> >>
> >> On Wed, 21 Nov 2018 at 22:18, Deng Xiaodong 
> wrote:
> >>
> >>> Hi,
> >>>
> >>> I believe only the folks who have write access to the codebase, i.e.
> the
> >>> committers, can stop/cancel/re-run the Travis CI jobs.
> >>>
> >>> What the contributors can do is to make commits to the branch in their
> >>> own fork & ensure it’s working/passing tests as expected, before they
> >>> create the Pull Request.
> >>>
> >>>
> >>> XD
> >>>
> >>> > On 22 Nov 2018, at 12:41 AM, Sai Phanindhra 
> >>> wrote:
> >>> >
> >>> > Deng Xiaodong thanks for helping us with this. I hope this will help
> >>> us in
> >>> > developing and testing fast. I would like to ask is there a provision
> >>> to
> >>> > cancel our own builds in travis. I can see sometimes contributors are
> >>> > pushing multiple commits in small intervals of time leading to
> multiple
> >>> > builds. If we can kill/cancel old builds and let only the latest
> build
> >>> run
> >>> > it would be better use of resources.
> >>> >
> >>> > On Wed, 21 Nov 2018 at 21:56, Deng Xiaodong 
> >>> wrote:
> >>> >
> >>> >> Hi folks,
> >>> >>
> >>> >> I noticed that testing is somehow a problem for some folks who would
> >>> like
> >>> >> to contribute (either have trouble setting local testing env, or
> >>> misused
> >>> >> Pull Request to test). Actually because Airflow is using Travis CI
> >>> for unit
> >>> >> testing, running testing for any of your change/commit is very very
> >>> easy.
> >>> >>
> >>> >> Steps
> >>> >> 1. Go to https://travis-ci.org/, click “Sign in with GitHub”. If
> you
> >>> >> haven’t done this before, possibly it will ask you to “Authorize
> >>> Travis CI
> >>> >> for Open Source”.
> >>> >> 2. After this is done, you may be redirected to
> >>> >> https://travis-ci.org/account/repositories. Then you will see a
> list
> >>> of
> >>> >> your public repositories. Let’s assume you have already forked
> >>> Airflow,
> >>> >> then just toggle it on.
> >>> >> 3. Everything is good to go! From now on, if you make any
> >>> change/commit to
> >>> >> your own fork of Airflow, the Travis CI test will be triggered
> >>> >> (Travis-related files is already included in the Airflow codebase).
> >>> >>
> >>> >> Why to do this
> >>> >> - You don’t have to set up local testing env, or misuse Pull Request
> >>> to
> >>> >> test your code change.
> >>> >> - Travis CI is free for Open Source project (public repo), but it
> only
> >>> >> allows 5 concurrent tests. On the other hand, Apache is using
> >>> >> paid-subscription (possibly for unlimited concurrent tests). So
> >>> mis-using
> >>> >> Pull Requests to test your change/commit will result in a slightly
> >>> bigger
> >>> >> bill that ASF receives.
> >>> >>
> >>> >> Hope this is somehow helpful for folks who would like to contribute.
> >>> >>
> >>> >> XD
> >>> >>
> >>> >
> >>> >
> >>> > --
> >>> > Sai Phanindhra,
> >>> > Ph: +91 9043258999
> >>>
> >>>
> >>
> >> --
> >> Sai Phanindhra,
> >> Ph: +91 9043258999
> >>
> >
> >
> > --
> >
> > Jarek Potiuk
> > Polidea  | Principal Software Engineer
> >
> > M: +48 660 796 129 <+48660796129>
> > E: jarek.pot...@polidea.com
> > [image: Polidea] 
> >
> > We create human & business stories through technology.
> > Check out our projects! 
> > [image: Github]  [image: Facebook]
> >  [image: Twitter]
> >  [image: Linkedin]
> >  [image: Instagram]
> >  [image: Behance]
> > 
> >
>
>
> --
> Sai Phanindhra,
> Ph: +91 9043258999
>


-- 

Jarek Potiuk
Polidea  | Principal Software Engineer

M: +48 660 796 129 <+48660796129>
E: jarek.pot...@polidea.com
[image: Polidea] 

We create human & business stories through technology.
Check out our projects! 

Re: Tip for Running Unit Testing against Your Own Fork

[Sai Phanindhra]

Some admin has to check. I am not sure what options they will be seeing.
They should have option to toggle auto cancel builds just like i had.

On Thu, 22 Nov 2018 at 14:21, Jarek Potiuk  wrote:

> There is - "auto cancellation" (see the screenshot). So maybe it's just a
> matter of flipping the toggle by the admins?
>
> [image: Screenshot 2018-11-22 at 09.49.27 (1).png]
>
> J.
>
>
>
>
> On Wed, Nov 21, 2018 at 6:19 PM Sai Phanindhra 
> wrote:
>
>> Hi,
>> I am not sure about that, there has to be a provision to stop multiple
>> builds same PR irrespective user's access to repo. I think admins have to
>> update settings of repo in travis.
>> [image: Screenshot 2018-11-21 at 10.46.11 PM.png]
>>
>> On Wed, 21 Nov 2018 at 22:18, Deng Xiaodong  wrote:
>>
>>> Hi,
>>>
>>> I believe only the folks who have write access to the codebase, i.e. the
>>> committers, can stop/cancel/re-run the Travis CI jobs.
>>>
>>> What the contributors can do is to make commits to the branch in their
>>> own fork & ensure it’s working/passing tests as expected, before they
>>> create the Pull Request.
>>>
>>>
>>> XD
>>>
>>> > On 22 Nov 2018, at 12:41 AM, Sai Phanindhra 
>>> wrote:
>>> >
>>> > Deng Xiaodong thanks for helping us with this. I hope this will help
>>> us in
>>> > developing and testing fast. I would like to ask is there a provision
>>> to
>>> > cancel our own builds in travis. I can see sometimes contributors are
>>> > pushing multiple commits in small intervals of time leading to multiple
>>> > builds. If we can kill/cancel old builds and let only the latest build
>>> run
>>> > it would be better use of resources.
>>> >
>>> > On Wed, 21 Nov 2018 at 21:56, Deng Xiaodong 
>>> wrote:
>>> >
>>> >> Hi folks,
>>> >>
>>> >> I noticed that testing is somehow a problem for some folks who would
>>> like
>>> >> to contribute (either have trouble setting local testing env, or
>>> misused
>>> >> Pull Request to test). Actually because Airflow is using Travis CI
>>> for unit
>>> >> testing, running testing for any of your change/commit is very very
>>> easy.
>>> >>
>>> >> Steps
>>> >> 1. Go to https://travis-ci.org/, click “Sign in with GitHub”. If you
>>> >> haven’t done this before, possibly it will ask you to “Authorize
>>> Travis CI
>>> >> for Open Source”.
>>> >> 2. After this is done, you may be redirected to
>>> >> https://travis-ci.org/account/repositories. Then you will see a list
>>> of
>>> >> your public repositories. Let’s assume you have already forked
>>> Airflow,
>>> >> then just toggle it on.
>>> >> 3. Everything is good to go! From now on, if you make any
>>> change/commit to
>>> >> your own fork of Airflow, the Travis CI test will be triggered
>>> >> (Travis-related files is already included in the Airflow codebase).
>>> >>
>>> >> Why to do this
>>> >> - You don’t have to set up local testing env, or misuse Pull Request
>>> to
>>> >> test your code change.
>>> >> - Travis CI is free for Open Source project (public repo), but it only
>>> >> allows 5 concurrent tests. On the other hand, Apache is using
>>> >> paid-subscription (possibly for unlimited concurrent tests). So
>>> mis-using
>>> >> Pull Requests to test your change/commit will result in a slightly
>>> bigger
>>> >> bill that ASF receives.
>>> >>
>>> >> Hope this is somehow helpful for folks who would like to contribute.
>>> >>
>>> >> XD
>>> >>
>>> >
>>> >
>>> > --
>>> > Sai Phanindhra,
>>> > Ph: +91 9043258999
>>>
>>>
>>
>> --
>> Sai Phanindhra,
>> Ph: +91 9043258999
>>
>
>
> --
>
> Jarek Potiuk
> Polidea  | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> E: jarek.pot...@polidea.com
> [image: Polidea] 
>
> We create human & business stories through technology.
> Check out our projects! 
> [image: Github]  [image: Facebook]
>  [image: Twitter]
>  [image: Linkedin]
>  [image: Instagram]
>  [image: Behance]
> 
>


-- 
Sai Phanindhra,
Ph: +91 9043258999

Re: Tip for Running Unit Testing against Your Own Fork

[Jarek Potiuk]

There is - "auto cancellation" (see the screenshot). So maybe it's just a
matter of flipping the toggle by the admins?

[image: Screenshot 2018-11-22 at 09.49.27 (1).png]

J.




On Wed, Nov 21, 2018 at 6:19 PM Sai Phanindhra  wrote:

> Hi,
> I am not sure about that, there has to be a provision to stop multiple
> builds same PR irrespective user's access to repo. I think admins have to
> update settings of repo in travis.
> [image: Screenshot 2018-11-21 at 10.46.11 PM.png]
>
> On Wed, 21 Nov 2018 at 22:18, Deng Xiaodong  wrote:
>
>> Hi,
>>
>> I believe only the folks who have write access to the codebase, i.e. the
>> committers, can stop/cancel/re-run the Travis CI jobs.
>>
>> What the contributors can do is to make commits to the branch in their
>> own fork & ensure it’s working/passing tests as expected, before they
>> create the Pull Request.
>>
>>
>> XD
>>
>> > On 22 Nov 2018, at 12:41 AM, Sai Phanindhra 
>> wrote:
>> >
>> > Deng Xiaodong thanks for helping us with this. I hope this will help us
>> in
>> > developing and testing fast. I would like to ask is there a provision to
>> > cancel our own builds in travis. I can see sometimes contributors are
>> > pushing multiple commits in small intervals of time leading to multiple
>> > builds. If we can kill/cancel old builds and let only the latest build
>> run
>> > it would be better use of resources.
>> >
>> > On Wed, 21 Nov 2018 at 21:56, Deng Xiaodong 
>> wrote:
>> >
>> >> Hi folks,
>> >>
>> >> I noticed that testing is somehow a problem for some folks who would
>> like
>> >> to contribute (either have trouble setting local testing env, or
>> misused
>> >> Pull Request to test). Actually because Airflow is using Travis CI for
>> unit
>> >> testing, running testing for any of your change/commit is very very
>> easy.
>> >>
>> >> Steps
>> >> 1. Go to https://travis-ci.org/, click “Sign in with GitHub”. If you
>> >> haven’t done this before, possibly it will ask you to “Authorize
>> Travis CI
>> >> for Open Source”.
>> >> 2. After this is done, you may be redirected to
>> >> https://travis-ci.org/account/repositories. Then you will see a list
>> of
>> >> your public repositories. Let’s assume you have already forked Airflow,
>> >> then just toggle it on.
>> >> 3. Everything is good to go! From now on, if you make any
>> change/commit to
>> >> your own fork of Airflow, the Travis CI test will be triggered
>> >> (Travis-related files is already included in the Airflow codebase).
>> >>
>> >> Why to do this
>> >> - You don’t have to set up local testing env, or misuse Pull Request to
>> >> test your code change.
>> >> - Travis CI is free for Open Source project (public repo), but it only
>> >> allows 5 concurrent tests. On the other hand, Apache is using
>> >> paid-subscription (possibly for unlimited concurrent tests). So
>> mis-using
>> >> Pull Requests to test your change/commit will result in a slightly
>> bigger
>> >> bill that ASF receives.
>> >>
>> >> Hope this is somehow helpful for folks who would like to contribute.
>> >>
>> >> XD
>> >>
>> >
>> >
>> > --
>> > Sai Phanindhra,
>> > Ph: +91 9043258999
>>
>>
>
> --
> Sai Phanindhra,
> Ph: +91 9043258999
>


-- 

Jarek Potiuk
Polidea  | Principal Software Engineer

M: +48 660 796 129 <+48660796129>
E: jarek.pot...@polidea.com
[image: Polidea] 

We create human & business stories through technology.
Check out our projects! 
[image: Github]  [image: Facebook]
 [image: Twitter]
 [image: Linkedin]
 [image: Instagram]
 [image: Behance]

Re: Tip for Running Unit Testing against Your Own Fork

[Sai Phanindhra]

Hi,
I am not sure about that, there has to be a provision to stop multiple
builds same PR irrespective user's access to repo. I think admins have to
update settings of repo in travis.
[image: Screenshot 2018-11-21 at 10.46.11 PM.png]

On Wed, 21 Nov 2018 at 22:18, Deng Xiaodong  wrote:

> Hi,
>
> I believe only the folks who have write access to the codebase, i.e. the
> committers, can stop/cancel/re-run the Travis CI jobs.
>
> What the contributors can do is to make commits to the branch in their own
> fork & ensure it’s working/passing tests as expected, before they create
> the Pull Request.
>
>
> XD
>
> > On 22 Nov 2018, at 12:41 AM, Sai Phanindhra  wrote:
> >
> > Deng Xiaodong thanks for helping us with this. I hope this will help us
> in
> > developing and testing fast. I would like to ask is there a provision to
> > cancel our own builds in travis. I can see sometimes contributors are
> > pushing multiple commits in small intervals of time leading to multiple
> > builds. If we can kill/cancel old builds and let only the latest build
> run
> > it would be better use of resources.
> >
> > On Wed, 21 Nov 2018 at 21:56, Deng Xiaodong  wrote:
> >
> >> Hi folks,
> >>
> >> I noticed that testing is somehow a problem for some folks who would
> like
> >> to contribute (either have trouble setting local testing env, or misused
> >> Pull Request to test). Actually because Airflow is using Travis CI for
> unit
> >> testing, running testing for any of your change/commit is very very
> easy.
> >>
> >> Steps
> >> 1. Go to https://travis-ci.org/, click “Sign in with GitHub”. If you
> >> haven’t done this before, possibly it will ask you to “Authorize Travis
> CI
> >> for Open Source”.
> >> 2. After this is done, you may be redirected to
> >> https://travis-ci.org/account/repositories. Then you will see a list of
> >> your public repositories. Let’s assume you have already forked Airflow,
> >> then just toggle it on.
> >> 3. Everything is good to go! From now on, if you make any change/commit
> to
> >> your own fork of Airflow, the Travis CI test will be triggered
> >> (Travis-related files is already included in the Airflow codebase).
> >>
> >> Why to do this
> >> - You don’t have to set up local testing env, or misuse Pull Request to
> >> test your code change.
> >> - Travis CI is free for Open Source project (public repo), but it only
> >> allows 5 concurrent tests. On the other hand, Apache is using
> >> paid-subscription (possibly for unlimited concurrent tests). So
> mis-using
> >> Pull Requests to test your change/commit will result in a slightly
> bigger
> >> bill that ASF receives.
> >>
> >> Hope this is somehow helpful for folks who would like to contribute.
> >>
> >> XD
> >>
> >
> >
> > --
> > Sai Phanindhra,
> > Ph: +91 9043258999
>
>

-- 
Sai Phanindhra,
Ph: +91 9043258999

Re: Tip for Running Unit Testing against Your Own Fork

[Deng Xiaodong]

Hi,

I believe only the folks who have write access to the codebase, i.e. the 
committers, can stop/cancel/re-run the Travis CI jobs.

What the contributors can do is to make commits to the branch in their own fork 
& ensure it’s working/passing tests as expected, before they create the Pull 
Request.


XD

> On 22 Nov 2018, at 12:41 AM, Sai Phanindhra  wrote:
> 
> Deng Xiaodong thanks for helping us with this. I hope this will help us in
> developing and testing fast. I would like to ask is there a provision to
> cancel our own builds in travis. I can see sometimes contributors are
> pushing multiple commits in small intervals of time leading to multiple
> builds. If we can kill/cancel old builds and let only the latest build run
> it would be better use of resources.
> 
> On Wed, 21 Nov 2018 at 21:56, Deng Xiaodong  wrote:
> 
>> Hi folks,
>> 
>> I noticed that testing is somehow a problem for some folks who would like
>> to contribute (either have trouble setting local testing env, or misused
>> Pull Request to test). Actually because Airflow is using Travis CI for unit
>> testing, running testing for any of your change/commit is very very easy.
>> 
>> Steps
>> 1. Go to https://travis-ci.org/, click “Sign in with GitHub”. If you
>> haven’t done this before, possibly it will ask you to “Authorize Travis CI
>> for Open Source”.
>> 2. After this is done, you may be redirected to
>> https://travis-ci.org/account/repositories. Then you will see a list of
>> your public repositories. Let’s assume you have already forked Airflow,
>> then just toggle it on.
>> 3. Everything is good to go! From now on, if you make any change/commit to
>> your own fork of Airflow, the Travis CI test will be triggered
>> (Travis-related files is already included in the Airflow codebase).
>> 
>> Why to do this
>> - You don’t have to set up local testing env, or misuse Pull Request to
>> test your code change.
>> - Travis CI is free for Open Source project (public repo), but it only
>> allows 5 concurrent tests. On the other hand, Apache is using
>> paid-subscription (possibly for unlimited concurrent tests). So mis-using
>> Pull Requests to test your change/commit will result in a slightly bigger
>> bill that ASF receives.
>> 
>> Hope this is somehow helpful for folks who would like to contribute.
>> 
>> XD
>> 
> 
> 
> -- 
> Sai Phanindhra,
> Ph: +91 9043258999

Re: Tip for Running Unit Testing against Your Own Fork

[Sai Phanindhra]

Deng Xiaodong thanks for helping us with this. I hope this will help us in
developing and testing fast. I would like to ask is there a provision to
cancel our own builds in travis. I can see sometimes contributors are
pushing multiple commits in small intervals of time leading to multiple
builds. If we can kill/cancel old builds and let only the latest build run
it would be better use of resources.

On Wed, 21 Nov 2018 at 21:56, Deng Xiaodong  wrote:

> Hi folks,
>
> I noticed that testing is somehow a problem for some folks who would like
> to contribute (either have trouble setting local testing env, or misused
> Pull Request to test). Actually because Airflow is using Travis CI for unit
> testing, running testing for any of your change/commit is very very easy.
>
> Steps
> 1. Go to https://travis-ci.org/, click “Sign in with GitHub”. If you
> haven’t done this before, possibly it will ask you to “Authorize Travis CI
> for Open Source”.
> 2. After this is done, you may be redirected to
> https://travis-ci.org/account/repositories. Then you will see a list of
> your public repositories. Let’s assume you have already forked Airflow,
> then just toggle it on.
> 3. Everything is good to go! From now on, if you make any change/commit to
> your own fork of Airflow, the Travis CI test will be triggered
> (Travis-related files is already included in the Airflow codebase).
>
> Why to do this
> - You don’t have to set up local testing env, or misuse Pull Request to
> test your code change.
> - Travis CI is free for Open Source project (public repo), but it only
> allows 5 concurrent tests. On the other hand, Apache is using
> paid-subscription (possibly for unlimited concurrent tests). So mis-using
> Pull Requests to test your change/commit will result in a slightly bigger
> bill that ASF receives.
>
> Hope this is somehow helpful for folks who would like to contribute.
>
> XD
>


-- 
Sai Phanindhra,
Ph: +91 9043258999