You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@weex.apache.org by 王仁敏 <wr...@gmail.com> on 2019/08/08 09:33:47 UTC
Some Suggestions about incubator-weex
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
Re: Some Suggestions about incubator-weex
Posted by York Shen <sh...@gmail.com>.
Actually, I never the number of Travis concurrent build in Weex is larger than 1, however, I do notice the maximum concurrent jobs in one build is five [1].
Anyway, I think we have no choice but live with limited Travis CI resource we have.
[1] https://docs.travis-ci.com/user/for-beginners/#builds-jobs-stages-and-phases <https://docs.travis-ci.com/user/for-beginners/#builds-jobs-stages-and-phases>
> 在 2019年8月19日，09:39，王仁敏 <wr...@gmail.com> 写道：
>
>
Re: Some Suggestions about incubator-weex
Posted by 王仁敏 <wr...@gmail.com>.
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 <sh...@gmail.com> 于2019年8月16日周五 下午5:05写道：
> Any information you can share with us?
>
> > 在 2019年8月8日，19:11，王仁敏 <wr...@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.
> >
> >
> > 申远 <sh...@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 <pi...@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 王仁敏 <wr...@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
> >>
>
>
Re: Some Suggestions about incubator-weex
Posted by York Shen <sh...@gmail.com>.
Any information you can share with us?
> 在 2019年8月8日，19:11，王仁敏 <wr...@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.
>
>
> 申远 <sh...@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 <pi...@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 王仁敏 <wr...@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
>>
Re: Some Suggestions about incubator-weex
Posted by York Shen <sh...@gmail.com>.
Status check to pass before merge is enabled now.
> 在 2019年8月8日，19:11，王仁敏 <wr...@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.
>
>
> 申远 <sh...@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 <pi...@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 王仁敏 <wr...@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
>>
Re: Some Suggestions about incubator-weex
Posted by 王仁敏 <wr...@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.
申远 <sh...@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 <pi...@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 王仁敏 <wr...@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
>
Re: Some Suggestions about incubator-weex
Posted by 申远 <sh...@gmail.com>.
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 <pi...@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 王仁敏 <wr...@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
Re: Some Suggestions about incubator-weex
Posted by Jan Piotrowski <pi...@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 王仁敏 <wr...@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