Status check to pass before merge is enabled now.
> 在 2019年8月8日，19:11，王仁敏 <wrmwindm...@gmail.com> 写道：
>
> Thanks for both of you.
>
> in Weex, we have tried to use Travis CI resources as less as possible. in
> Weex the Travis CI job will early stop if it don't need to run continue.
> for example, if there are not android file changed, the android lint check
> job and android check job will stop once it enter script pharse (the
> pharses before script pharse are forced to execute by Travis CI )
>
> of course I will create a JIRA issue to INFRA to find out how ASF
> Infra manage Travis resource.
>
>
> 申远 <shenyua...@gmail.com> 于2019年8月8日周四 下午6:26写道：
>
>> I totally agreed your first point and I shall create a JIRA ticket to INFRA
>> to let it happen.
>>
>> As for your second point, I found a JIRA issue about this. I am pretty Weex
>> doesn’t use Travis resource as Apache Flink did [1]. (No offense)
>>
>> Our rough metrics shows that Flink used over 5800 hours of build time last
>>> month. That is equal to EIGHT servers running 24/7 for the ENTIRE MONTH.
>>> EIGHT. nonstop.
>>>
>>
>> Maybe we could ask INFRA to find the rules about how ASF INFRA share the CI
>> resource. Is it guarantee an equal share for every Apache projects ? And is
>> there a rule about the maximum Travis jobs/builds. It seems like we can
>> have as many jobs as possible in each build, and all the jobs
>> runs concurrently. But we are only allowed to run 1 Travis Build at
>> any given time, other builds must wait. These rules is a little strange to
>> me.
>>
>> @Renmin Could you please help to find out about the rules of how ASF Infra
>> manage Travis resource? Just create a JIRA issue to INFRA [2], thanks.
>>
>>
>> [1] https://issues.apache.org/jira/browse/INFRA-18533
>> [2] https://issues.apache.org/jira/projects/INFRA/issues
>>
>> 在 2019年8月8日，17:46，Jan Piotrowski <piotrow...@gmail.com> 写道：
>>
>> Unfortunately there is no way to fix your second point when working in
>> the apache/* repositories as far as I know.
>> This is the account of Apache Software Foundation, which is shared
>> between all projects.
>> If you fork the repo and work in your own namespace, you can use your
>> own Travis account and have much quicker build times.
>>
>> J
>>
>> Am Do., 8. Aug. 2019 um 11:34 Uhr schrieb 王仁敏 <wrmwindm...@gmail.com>:
>>
>>
>> Those day I spend some time updating Travis CI of incubator-weex, during
>> the development process, I found some problems and the below is my
>> suggestion,
>>
>> # FIrst I recommend prohibiting merging the PR that Travis CI builds failed
>>
>> Travis CI build failed means that there is something wrong. If we force to
>> merge the PR, it will lead to bugs even crash. We should Prohibited force
>> merge PR that Travis CI builds failed into the main branch. (but the
>> committer now has permission to merge the PRs that failed Travis CI build
>> failed, and there have been some cases where PR builds failed but were
>> merged into the main branch.)
>>
>> # Second, I recommend increasing Travis CI's resources
>>
>> Now Weex's Travis CI does not allow parallel builds, which means that new
>> Travis CI job must wait until the existing Travis CI job complete.
>>
>> But It takes about 20 minutes to build a Travis CI once now, with more and
>> more checks will be added to Travis CI, the wait time will get longer and
>> longer, even unbearable.
>>
>> Best regards.
>> Renmin Wang
>>
