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 >
