1. All projects using Travis share the same pool of resources. 2. The ASF pays Travis for ~40 builders. each project is limited to no more than 5 concurrent builds.
links： 1. https://issues.apache.org/jira/browse/INFRA-18862 2. https://issues.apache.org/jira/browse/INFRA-18892 York Shen <[email protected]> 于2019年8月16日周五 下午5:05写道： > Any information you can share with us? > > > 在 2019年8月8日，19:11，王仁敏 <[email protected]> 写道： > > > > 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. > > > > > > 申远 <[email protected]> 于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 <[email protected]> 写道： > >> > >> 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 王仁敏 <[email protected]>: > >> > >> > >> 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 > >> > >
