You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@dubbo.apache.org by Albumen Kevin <al...@apache.org> on 2021/03/05 06:59:29 UTC
[Discuss] Disable Travis CI for apache/dubbo
Hi community,
So far, we have enable two kinds of CI/CD platform , Travis CI and
GitHub Actions, for Dubbo. GitHub actions works fine for Dubbo
in 2.6.x[1], 2.7.x[2] and 3.x[3] versions.
In 2.7.x and 3.x versions, both unit test and integration test[4], based
on apache/dubbo-samples, are introduced to guarantee the stability
of the snapshot version.
There are some benefits can be provided by GitHub Actions now:
- More powerful ecosystem
- Easy integration with more GitHub activity
- Can be launched at any time because it is no need
for us to share the concurrency limit with all projects.
Also the concurrency limit for each project looks enough for us.
I am wondering if we could disable Travis CI for now which function
can be completely replaced with GitHub Actions?
[1] https://github.com/apache/dubbo/actions/runs/623019397
[2] https://github.com/apache/dubbo/actions/runs/620506574
[3] https://github.com/apache/dubbo/actions/runs/620213136
[4] https://github.com/apache/dubbo/runs/2029991040
Re: [Discuss] Disable Travis CI for apache/dubbo
Posted by Xin Wang <xi...@gmail.com>.
Agree, since Github Actions have become more and more powerful
Albumen Kevin <al...@apache.org> 于2021年3月5日周五 下午2:59写道：
> Hi community,
>
>
> So far, we have enable two kinds of CI/CD platform , Travis CI and
>
> GitHub Actions, for Dubbo. GitHub actions works fine for Dubbo
>
> in 2.6.x[1], 2.7.x[2] and 3.x[3] versions.
>
> In 2.7.x and 3.x versions, both unit test and integration test[4], based
>
> on apache/dubbo-samples, are introduced to guarantee the stability
>
> of the snapshot version.
>
>
> There are some benefits can be provided by GitHub Actions now:
>
>
> - More powerful ecosystem
>
> - Easy integration with more GitHub activity
>
> - Can be launched at any time because it is no need
>
> for us to share the concurrency limit with all projects.
>
> Also the concurrency limit for each project looks enough for us.
>
>
> I am wondering if we could disable Travis CI for now which function
>
> can be completely replaced with GitHub Actions?
>
>
> [1] https://github.com/apache/dubbo/actions/runs/623019397
>
> [2] https://github.com/apache/dubbo/actions/runs/620506574
>
> [3] https://github.com/apache/dubbo/actions/runs/620213136
>
> [4] https://github.com/apache/dubbo/runs/2029991040
>
回复: [Discuss] Disable Travis CI for apache/dubbo
Posted by Justin W <le...@live.cn>.
+1 switch to GitHub action.
________________________________
发件人: Albumen Kevin <jh...@gmail.com>
发送时间: 2021年3月9日 11:28
收件人: dev@dubbo.apache.org <de...@dubbo.apache.org>
主题: Re: [Discuss] Disable Travis CI for apache/dubbo
Hi community,
I will disable Travis CI later.
Also we can obtain the CI/CD result from GitHub Actions [1].
Thanks all.
[1] https://github.com/apache/dubbo/actions
On Fri, Mar 5, 2021 at 4:07 PM Ian Luo <ia...@gmail.com> wrote:
> +1 to switch to GitHub action.
>
> -Ian.
>
> On Fri, Mar 5, 2021 at 2:59 PM Albumen Kevin <al...@apache.org> wrote:
>
> > Hi community,
> >
> >
> > So far, we have enable two kinds of CI/CD platform , Travis CI and
> >
> > GitHub Actions, for Dubbo. GitHub actions works fine for Dubbo
> >
> > in 2.6.x[1], 2.7.x[2] and 3.x[3] versions.
> >
> > In 2.7.x and 3.x versions, both unit test and integration test[4], based
> >
> > on apache/dubbo-samples, are introduced to guarantee the stability
> >
> > of the snapshot version.
> >
> >
> > There are some benefits can be provided by GitHub Actions now:
> >
> >
> > - More powerful ecosystem
> >
> > - Easy integration with more GitHub activity
> >
> > - Can be launched at any time because it is no need
> >
> > for us to share the concurrency limit with all projects.
> >
> > Also the concurrency limit for each project looks enough for us.
> >
> >
> > I am wondering if we could disable Travis CI for now which function
> >
> > can be completely replaced with GitHub Actions?
> >
> >
> > [1] https://github.com/apache/dubbo/actions/runs/623019397
> >
> > [2] https://github.com/apache/dubbo/actions/runs/620506574
> >
> > [3] https://github.com/apache/dubbo/actions/runs/620213136
> >
> > [4] https://github.com/apache/dubbo/runs/2029991040
> >
>
Re: [Discuss] Disable Travis CI for apache/dubbo
Posted by joezou <jo...@apache.org>.
+1 to switch to GitHub action.
wongoo <wo...@apache.org> 于2021年3月9日周二 上午11:58写道：
> +1 to switch to GitHub action.
>
> On Tue, Mar 9, 2021 at 11:28 AM Albumen Kevin <jh...@gmail.com> wrote:
>
> > Hi community,
> >
> > I will disable Travis CI later.
> > Also we can obtain the CI/CD result from GitHub Actions [1].
> > Thanks all.
> >
> > [1] https://github.com/apache/dubbo/actions
> >
> > On Fri, Mar 5, 2021 at 4:07 PM Ian Luo <ia...@gmail.com> wrote:
> >
> > > +1 to switch to GitHub action.
> > >
> > > -Ian.
> > >
> > > On Fri, Mar 5, 2021 at 2:59 PM Albumen Kevin <al...@apache.org>
> > wrote:
> > >
> > > > Hi community,
> > > >
> > > >
> > > > So far, we have enable two kinds of CI/CD platform , Travis CI and
> > > >
> > > > GitHub Actions, for Dubbo. GitHub actions works fine for Dubbo
> > > >
> > > > in 2.6.x[1], 2.7.x[2] and 3.x[3] versions.
> > > >
> > > > In 2.7.x and 3.x versions, both unit test and integration test[4],
> > based
> > > >
> > > > on apache/dubbo-samples, are introduced to guarantee the stability
> > > >
> > > > of the snapshot version.
> > > >
> > > >
> > > > There are some benefits can be provided by GitHub Actions now:
> > > >
> > > >
> > > > - More powerful ecosystem
> > > >
> > > > - Easy integration with more GitHub activity
> > > >
> > > > - Can be launched at any time because it is no need
> > > >
> > > > for us to share the concurrency limit with all projects.
> > > >
> > > > Also the concurrency limit for each project looks enough for us.
> > > >
> > > >
> > > > I am wondering if we could disable Travis CI for now which function
> > > >
> > > > can be completely replaced with GitHub Actions?
> > > >
> > > >
> > > > [1] https://github.com/apache/dubbo/actions/runs/623019397
> > > >
> > > > [2] https://github.com/apache/dubbo/actions/runs/620506574
> > > >
> > > > [3] https://github.com/apache/dubbo/actions/runs/620213136
> > > >
> > > > [4] https://github.com/apache/dubbo/runs/2029991040
> > > >
> > >
> >
>
>
> --
> Regards,
> Wongoo
>
Re: [Discuss] Disable Travis CI for apache/dubbo
Posted by wongoo <wo...@apache.org>.
+1 to switch to GitHub action.
On Tue, Mar 9, 2021 at 11:28 AM Albumen Kevin <jh...@gmail.com> wrote:
> Hi community,
>
> I will disable Travis CI later.
> Also we can obtain the CI/CD result from GitHub Actions [1].
> Thanks all.
>
> [1] https://github.com/apache/dubbo/actions
>
> On Fri, Mar 5, 2021 at 4:07 PM Ian Luo <ia...@gmail.com> wrote:
>
> > +1 to switch to GitHub action.
> >
> > -Ian.
> >
> > On Fri, Mar 5, 2021 at 2:59 PM Albumen Kevin <al...@apache.org>
> wrote:
> >
> > > Hi community,
> > >
> > >
> > > So far, we have enable two kinds of CI/CD platform , Travis CI and
> > >
> > > GitHub Actions, for Dubbo. GitHub actions works fine for Dubbo
> > >
> > > in 2.6.x[1], 2.7.x[2] and 3.x[3] versions.
> > >
> > > In 2.7.x and 3.x versions, both unit test and integration test[4],
> based
> > >
> > > on apache/dubbo-samples, are introduced to guarantee the stability
> > >
> > > of the snapshot version.
> > >
> > >
> > > There are some benefits can be provided by GitHub Actions now:
> > >
> > >
> > > - More powerful ecosystem
> > >
> > > - Easy integration with more GitHub activity
> > >
> > > - Can be launched at any time because it is no need
> > >
> > > for us to share the concurrency limit with all projects.
> > >
> > > Also the concurrency limit for each project looks enough for us.
> > >
> > >
> > > I am wondering if we could disable Travis CI for now which function
> > >
> > > can be completely replaced with GitHub Actions?
> > >
> > >
> > > [1] https://github.com/apache/dubbo/actions/runs/623019397
> > >
> > > [2] https://github.com/apache/dubbo/actions/runs/620506574
> > >
> > > [3] https://github.com/apache/dubbo/actions/runs/620213136
> > >
> > > [4] https://github.com/apache/dubbo/runs/2029991040
> > >
> >
>
--
Regards,
Wongoo
Re: [Discuss] Disable Travis CI for apache/dubbo
Posted by Albumen Kevin <jh...@gmail.com>.
Hi community,
I will disable Travis CI later.
Also we can obtain the CI/CD result from GitHub Actions [1].
Thanks all.
[1] https://github.com/apache/dubbo/actions
On Fri, Mar 5, 2021 at 4:07 PM Ian Luo <ia...@gmail.com> wrote:
> +1 to switch to GitHub action.
>
> -Ian.
>
> On Fri, Mar 5, 2021 at 2:59 PM Albumen Kevin <al...@apache.org> wrote:
>
> > Hi community,
> >
> >
> > So far, we have enable two kinds of CI/CD platform , Travis CI and
> >
> > GitHub Actions, for Dubbo. GitHub actions works fine for Dubbo
> >
> > in 2.6.x[1], 2.7.x[2] and 3.x[3] versions.
> >
> > In 2.7.x and 3.x versions, both unit test and integration test[4], based
> >
> > on apache/dubbo-samples, are introduced to guarantee the stability
> >
> > of the snapshot version.
> >
> >
> > There are some benefits can be provided by GitHub Actions now:
> >
> >
> > - More powerful ecosystem
> >
> > - Easy integration with more GitHub activity
> >
> > - Can be launched at any time because it is no need
> >
> > for us to share the concurrency limit with all projects.
> >
> > Also the concurrency limit for each project looks enough for us.
> >
> >
> > I am wondering if we could disable Travis CI for now which function
> >
> > can be completely replaced with GitHub Actions?
> >
> >
> > [1] https://github.com/apache/dubbo/actions/runs/623019397
> >
> > [2] https://github.com/apache/dubbo/actions/runs/620506574
> >
> > [3] https://github.com/apache/dubbo/actions/runs/620213136
> >
> > [4] https://github.com/apache/dubbo/runs/2029991040
> >
>
Re: [Discuss] Disable Travis CI for apache/dubbo
Posted by Ian Luo <ia...@gmail.com>.
+1 to switch to GitHub action.
-Ian.
On Fri, Mar 5, 2021 at 2:59 PM Albumen Kevin <al...@apache.org> wrote:
> Hi community,
>
>
> So far, we have enable two kinds of CI/CD platform , Travis CI and
>
> GitHub Actions, for Dubbo. GitHub actions works fine for Dubbo
>
> in 2.6.x[1], 2.7.x[2] and 3.x[3] versions.
>
> In 2.7.x and 3.x versions, both unit test and integration test[4], based
>
> on apache/dubbo-samples, are introduced to guarantee the stability
>
> of the snapshot version.
>
>
> There are some benefits can be provided by GitHub Actions now:
>
>
> - More powerful ecosystem
>
> - Easy integration with more GitHub activity
>
> - Can be launched at any time because it is no need
>
> for us to share the concurrency limit with all projects.
>
> Also the concurrency limit for each project looks enough for us.
>
>
> I am wondering if we could disable Travis CI for now which function
>
> can be completely replaced with GitHub Actions?
>
>
> [1] https://github.com/apache/dubbo/actions/runs/623019397
>
> [2] https://github.com/apache/dubbo/actions/runs/620506574
>
> [3] https://github.com/apache/dubbo/actions/runs/620213136
>
> [4] https://github.com/apache/dubbo/runs/2029991040
>
Re:[Discuss] Disable Travis CI for apache/dubbo
Posted by ranke <21...@qq.com>.
I think we can close disable Travis CI, it's too inefficient, and two CI are unnecessary
------------------ Original ------------------
From: "Albumen Kevin"<albumenj@apache.org>;
Date: 2021年3月5日(星期五) 下午2:59
To: "dev"<dev@dubbo.apache.org>;
Subject: [Discuss] Disable Travis CI for apache/dubbo
Hi community,
So far, we have enable two kinds of CI/CD platform , Travis CI and
GitHub Actions, for Dubbo. GitHub actions works fine for Dubbo
in 2.6.x[1], 2.7.x[2] and 3.x[3] versions.
In 2.7.x and 3.x versions, both unit test and integration test[4], based
on apache/dubbo-samples, are introduced to guarantee the stability
of the snapshot version.
There are some benefits can be provided by GitHub Actions now:
- More powerful ecosystem
- Easy integration with more GitHub activity
- Can be launched at any time because it is no need
for us to share the concurrency limit with all projects.
Also the concurrency limit for each project looks enough for us.
I am wondering if we could disable Travis CI for now which function
can be completely replaced with GitHub Actions?
[1] https://github.com/apache/dubbo/actions/runs/623019397
[2] https://github.com/apache/dubbo/actions/runs/620506574
[3] https://github.com/apache/dubbo/actions/runs/620213136
[4] https://github.com/apache/dubbo/runs/2029991040
Re: [Discuss] Disable Travis CI for apache/dubbo
Posted by Martin Tzvetanov Grigorov <mg...@apache.org>.
Hi,
All the issues are fixed and now the build and tests pass successfully on ARM64!
https://github.com/apache/dubbo/pull/7408
Once merged someone who has write permissions at TravisCI will have to setup the cron job to run the build every night - https://docs.travis-ci.com/user/cron-jobs/
Regards,
Martin
On 2021/03/16 13:49:19, Martin Tzvetanov Grigorov <mg...@apache.org> wrote:
> Hi Albumen,
>
> On 2021/03/13 14:40:13, Albumen Kevin <al...@apache.org> wrote:
> > Hi Martin,
> >
> > Actually with the help of Docker and QEMU it is not that hard!
> > > In short you just need to do:
> > > - docker run -it — rm — privileged multiarch/qemu-user-static —
> > > credential yes — persistent yes
> > > - docker run -it — rm arm64v8/ubuntu:focal bash
> >
> >
> > That's awesome. Could you please introduce it to the contribution guide[1]
> > to instruct contributors how to build an ARM64 env?
>
> I will update this guide with my PR!
>
> >
> > Yes, this is why I suggested the ARM64 build+test to be "unofficial", i.e.
> > > we can add it to "allow_failures" section of .travis.yml and this way it
> > > won't stop the merging of the PRs.
> > > But then the question would be whether anyone would bother to check the
> > > build status :-)
> >
> >
> > It seems as if nightly building is a good choice? Also, this will not block
> > pull request processes and we can mention it in the latest master branch.
>
> OK! I will use a cron job to run it nightly at TravisCI!
>
> >
> > At the moment embedded-redis is the only problem for `mvn install`.
> > > Is there anything else I could test on my ARM64 VM ?
> >
> >
> > The following command (you can find it in build-and-test.yml [2]) is used
> > to make unit tests for Dubbo in Ubuntu x86 env. You can try it on ARM64.
> >
> > ./mvnw --batch-mode -U -e --no-transfer-progress clean test
> > > -Dmaven.wagon.httpconnectionManager.ttlSeconds=120
> > > -Dmaven.wagon.http.retryHandler.count=5 -DskipTests=false
> > > -DskipIntegrationTests=false -Dcheckstyle.skip=false -Drat.skip=false
> > > -Dmaven.javadoc.skip=true
>
> Thanks for this!
> It revealed a problem with Embedded Consul too.
>
> Regards,
> Martin
>
> >
> >
> > [1] https://github.com/apache/dubbo/blob/master/CONTRIBUTING.md
> > [2]
> > https://github.com/apache/dubbo/blob/master/.github/workflows/build-and-test.yml
> >
> > Albumen
> >
> >
> > On Thu, Mar 11, 2021 at 4:03 PM Martin Tzvetanov Grigorov <
> > mgrigorov@apache.org> wrote:
> >
> > > Hi Albumen,
> > >
> > > Please see inline.
> > >
> > > On 2021/03/10 15:13:23, Albumen Kevin <al...@apache.org> wrote:
> > > > Hi Martin,
> > > >
> > > > Thanks for your suggestion. I agree with you that ARM64 is an important
> > > > platform for us and we should adapt it in the future.
> > > >
> > > > For Dubbo, there isn't enough test for ARM64, and I think this may be a
> > > > problem for Dubbo to adapt ARM64 due to both Dubbo itself and
> > > dependencies.
> > > > It might not be a good choice for contributors to make sure their code
> > > can
> > > > work fine on ARM64. One is it is hard for someone to own an ARM64
> > >
> > > Actually with the help of Docker and QEMU it is not that hard!
> > > In short you just need to do:
> > > - docker run -it — rm — privileged multiarch/qemu-user-static —
> > > credential yes — persistent yes
> > > - docker run -it — rm arm64v8/ubuntu:focal bash
> > >
> > > I.e. enable QEMU/binfmt on the host (i.e. your dev machine) and then run
> > > any ARM64 Docker image and develop/debug whatever you need.
> > >
> > > I've explained it in more details at
> > > https://martin-grigorov.medium.com/building-linux-packages-for-different-cpu-architectures-with-docker-and-qemu-d29e4ebc9fa5
> > >
> > > > environment, the other one is would it cause more time to wait for a PR
> > > > since it passes CI / CD.
> > >
> > > Yes, this is why I suggested the ARM64 build+test to be "unofficial", i.e.
> > > we can add it to "allow_failures" section of .travis.yml and this way it
> > > won't stop the merging of the PRs.
> > > But then the question would be whether anyone would bother to check the
> > > build status :-)
> > >
> > > >
> > > > Currently, the integration test framework has not been adapted to Travis
> > > > CI, which means we can only test unit test cases for now. Also, I am sure
> > > > the integration test framework can also be transplanted to Travis CI.
> > > >
> > > > In my opinion, we can try to reintroduce TravisCI as a nightly tester and
> > > > make Dubbo more stable, but before this, we should make sure the latest
> > > > version source on master branch can work fine on ARM64.I am afraid that
> > > > there might not only embedded-redis stop Dubbo adapt ARM64.
> > >
> > > At the moment embedded-redis is the only problem for `mvn install`.
> > > Is there anything else I could test on my ARM64 VM ?
> > >
> > > The problem with embedded-resis library is that the official project is no
> > > more maintained and there are few hundreds forks of it (262,
> > > https://github.com/kstyrc/embedded-redis/network/members) and most of
> > > them again don't want to be the new official ancestor, i.e. to improve it
> > > and make new releases of it.
> > >
> > > >
> > > > Also, if Github Actions plans for ARM64 support, these things can be more
> > > > easier !
> > >
> > > YES! That would be the best!
> > >
> > > I'll keep you posted!
> > >
> > > Regards,
> > > Martin
> > >
> > > >
> > > > Albumen
> > > >
> > > >
> > > > On Wed, Mar 10, 2021 at 10:20 PM Martin Tzvetanov Grigorov <
> > > > mgrigorov@apache.org> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I see that you already dropped TravisCI -
> > > > >
> > > https://github.com/apache/dubbo/commit/cc3fb913e03424f62863c8536075be0fd04f12f2
> > > > >
> > > > > I fully agree that GitHub Actions is the better CI these days, but
> > > there
> > > > > is one thing that Travis has that the others don't: support for
> > > non-x86_64
> > > > > architectures like ARM64 and s390x.
> > > > > More and more server deployments are being done on ARM64 in the last
> > > few
> > > > > years.
> > > > > I was hoping to add a new job at TravisCI to build and test on ARM64
> > > but
> > > > > at the moment there is one stopper - embedded-redis does not support
> > > ARM64,
> > > > > because it does not have a native binary for redis-server in the jar.
> > > > > I've created two Pull Requests for forks which have recent releases:
> > > > > - https://github.com/signalapp/embedded-redis/pull/8
> > > > > - https://github.com/codemonstur/embedded-redis/pull/1
> > > > > but they are not yet reviewed and merged.
> > > > >
> > > > > Would it be OK for you to re-introduce TravisCI as unofficial CI for
> > > ARM64
> > > > > once the issue with embedded-redis is resolved ?
> > > > >
> > > > > Apache Infra plans to have a call with GitHub Actions representative -
> > > > >
> > > https://cwiki.apache.org/confluence/display/INFRA/Builds+Agenda+2021-03-11
> > > .
> > > > > I am going to ask about their plans for ARM64 support and then TravisCI
> > > > > could be forgotten for good!
> > > > >
> > > > > Regards,
> > > > > Martin
> > > > >
> > > > >
> > > > > On 2021/03/05 06:59:29, Albumen Kevin <al...@apache.org> wrote:
> > > > > > Hi community,
> > > > > >
> > > > > >
> > > > > > So far, we have enable two kinds of CI/CD platform , Travis CI and
> > > > > >
> > > > > > GitHub Actions, for Dubbo. GitHub actions works fine for Dubbo
> > > > > >
> > > > > > in 2.6.x[1], 2.7.x[2] and 3.x[3] versions.
> > > > > >
> > > > > > In 2.7.x and 3.x versions, both unit test and integration test[4],
> > > based
> > > > > >
> > > > > > on apache/dubbo-samples, are introduced to guarantee the stability
> > > > > >
> > > > > > of the snapshot version.
> > > > > >
> > > > > >
> > > > > > There are some benefits can be provided by GitHub Actions now:
> > > > > >
> > > > > >
> > > > > > - More powerful ecosystem
> > > > > >
> > > > > > - Easy integration with more GitHub activity
> > > > > >
> > > > > > - Can be launched at any time because it is no need
> > > > > >
> > > > > > for us to share the concurrency limit with all projects.
> > > > > >
> > > > > > Also the concurrency limit for each project looks enough for us.
> > > > > >
> > > > > >
> > > > > > I am wondering if we could disable Travis CI for now which function
> > > > > >
> > > > > > can be completely replaced with GitHub Actions?
> > > > > >
> > > > > >
> > > > > > [1] https://github.com/apache/dubbo/actions/runs/623019397
> > > > > >
> > > > > > [2] https://github.com/apache/dubbo/actions/runs/620506574
> > > > > >
> > > > > > [3] https://github.com/apache/dubbo/actions/runs/620213136
> > > > > >
> > > > > > [4] https://github.com/apache/dubbo/runs/2029991040
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [Discuss] Disable Travis CI for apache/dubbo
Posted by Martin Tzvetanov Grigorov <mg...@apache.org>.
Hi Albumen,
On 2021/03/13 14:40:13, Albumen Kevin <al...@apache.org> wrote:
> Hi Martin,
>
> Actually with the help of Docker and QEMU it is not that hard!
> > In short you just need to do:
> > - docker run -it — rm — privileged multiarch/qemu-user-static —
> > credential yes — persistent yes
> > - docker run -it — rm arm64v8/ubuntu:focal bash
>
>
> That's awesome. Could you please introduce it to the contribution guide[1]
> to instruct contributors how to build an ARM64 env?
I will update this guide with my PR!
>
> Yes, this is why I suggested the ARM64 build+test to be "unofficial", i.e.
> > we can add it to "allow_failures" section of .travis.yml and this way it
> > won't stop the merging of the PRs.
> > But then the question would be whether anyone would bother to check the
> > build status :-)
>
>
> It seems as if nightly building is a good choice? Also, this will not block
> pull request processes and we can mention it in the latest master branch.
OK! I will use a cron job to run it nightly at TravisCI!
>
> At the moment embedded-redis is the only problem for `mvn install`.
> > Is there anything else I could test on my ARM64 VM ?
>
>
> The following command (you can find it in build-and-test.yml [2]) is used
> to make unit tests for Dubbo in Ubuntu x86 env. You can try it on ARM64.
>
> ./mvnw --batch-mode -U -e --no-transfer-progress clean test
> > -Dmaven.wagon.httpconnectionManager.ttlSeconds=120
> > -Dmaven.wagon.http.retryHandler.count=5 -DskipTests=false
> > -DskipIntegrationTests=false -Dcheckstyle.skip=false -Drat.skip=false
> > -Dmaven.javadoc.skip=true
Thanks for this!
It revealed a problem with Embedded Consul too.
Regards,
Martin
>
>
> [1] https://github.com/apache/dubbo/blob/master/CONTRIBUTING.md
> [2]
> https://github.com/apache/dubbo/blob/master/.github/workflows/build-and-test.yml
>
> Albumen
>
>
> On Thu, Mar 11, 2021 at 4:03 PM Martin Tzvetanov Grigorov <
> mgrigorov@apache.org> wrote:
>
> > Hi Albumen,
> >
> > Please see inline.
> >
> > On 2021/03/10 15:13:23, Albumen Kevin <al...@apache.org> wrote:
> > > Hi Martin,
> > >
> > > Thanks for your suggestion. I agree with you that ARM64 is an important
> > > platform for us and we should adapt it in the future.
> > >
> > > For Dubbo, there isn't enough test for ARM64, and I think this may be a
> > > problem for Dubbo to adapt ARM64 due to both Dubbo itself and
> > dependencies.
> > > It might not be a good choice for contributors to make sure their code
> > can
> > > work fine on ARM64. One is it is hard for someone to own an ARM64
> >
> > Actually with the help of Docker and QEMU it is not that hard!
> > In short you just need to do:
> > - docker run -it — rm — privileged multiarch/qemu-user-static —
> > credential yes — persistent yes
> > - docker run -it — rm arm64v8/ubuntu:focal bash
> >
> > I.e. enable QEMU/binfmt on the host (i.e. your dev machine) and then run
> > any ARM64 Docker image and develop/debug whatever you need.
> >
> > I've explained it in more details at
> > https://martin-grigorov.medium.com/building-linux-packages-for-different-cpu-architectures-with-docker-and-qemu-d29e4ebc9fa5
> >
> > > environment, the other one is would it cause more time to wait for a PR
> > > since it passes CI / CD.
> >
> > Yes, this is why I suggested the ARM64 build+test to be "unofficial", i.e.
> > we can add it to "allow_failures" section of .travis.yml and this way it
> > won't stop the merging of the PRs.
> > But then the question would be whether anyone would bother to check the
> > build status :-)
> >
> > >
> > > Currently, the integration test framework has not been adapted to Travis
> > > CI, which means we can only test unit test cases for now. Also, I am sure
> > > the integration test framework can also be transplanted to Travis CI.
> > >
> > > In my opinion, we can try to reintroduce TravisCI as a nightly tester and
> > > make Dubbo more stable, but before this, we should make sure the latest
> > > version source on master branch can work fine on ARM64.I am afraid that
> > > there might not only embedded-redis stop Dubbo adapt ARM64.
> >
> > At the moment embedded-redis is the only problem for `mvn install`.
> > Is there anything else I could test on my ARM64 VM ?
> >
> > The problem with embedded-resis library is that the official project is no
> > more maintained and there are few hundreds forks of it (262,
> > https://github.com/kstyrc/embedded-redis/network/members) and most of
> > them again don't want to be the new official ancestor, i.e. to improve it
> > and make new releases of it.
> >
> > >
> > > Also, if Github Actions plans for ARM64 support, these things can be more
> > > easier !
> >
> > YES! That would be the best!
> >
> > I'll keep you posted!
> >
> > Regards,
> > Martin
> >
> > >
> > > Albumen
> > >
> > >
> > > On Wed, Mar 10, 2021 at 10:20 PM Martin Tzvetanov Grigorov <
> > > mgrigorov@apache.org> wrote:
> > >
> > > > Hi,
> > > >
> > > > I see that you already dropped TravisCI -
> > > >
> > https://github.com/apache/dubbo/commit/cc3fb913e03424f62863c8536075be0fd04f12f2
> > > >
> > > > I fully agree that GitHub Actions is the better CI these days, but
> > there
> > > > is one thing that Travis has that the others don't: support for
> > non-x86_64
> > > > architectures like ARM64 and s390x.
> > > > More and more server deployments are being done on ARM64 in the last
> > few
> > > > years.
> > > > I was hoping to add a new job at TravisCI to build and test on ARM64
> > but
> > > > at the moment there is one stopper - embedded-redis does not support
> > ARM64,
> > > > because it does not have a native binary for redis-server in the jar.
> > > > I've created two Pull Requests for forks which have recent releases:
> > > > - https://github.com/signalapp/embedded-redis/pull/8
> > > > - https://github.com/codemonstur/embedded-redis/pull/1
> > > > but they are not yet reviewed and merged.
> > > >
> > > > Would it be OK for you to re-introduce TravisCI as unofficial CI for
> > ARM64
> > > > once the issue with embedded-redis is resolved ?
> > > >
> > > > Apache Infra plans to have a call with GitHub Actions representative -
> > > >
> > https://cwiki.apache.org/confluence/display/INFRA/Builds+Agenda+2021-03-11
> > .
> > > > I am going to ask about their plans for ARM64 support and then TravisCI
> > > > could be forgotten for good!
> > > >
> > > > Regards,
> > > > Martin
> > > >
> > > >
> > > > On 2021/03/05 06:59:29, Albumen Kevin <al...@apache.org> wrote:
> > > > > Hi community,
> > > > >
> > > > >
> > > > > So far, we have enable two kinds of CI/CD platform , Travis CI and
> > > > >
> > > > > GitHub Actions, for Dubbo. GitHub actions works fine for Dubbo
> > > > >
> > > > > in 2.6.x[1], 2.7.x[2] and 3.x[3] versions.
> > > > >
> > > > > In 2.7.x and 3.x versions, both unit test and integration test[4],
> > based
> > > > >
> > > > > on apache/dubbo-samples, are introduced to guarantee the stability
> > > > >
> > > > > of the snapshot version.
> > > > >
> > > > >
> > > > > There are some benefits can be provided by GitHub Actions now:
> > > > >
> > > > >
> > > > > - More powerful ecosystem
> > > > >
> > > > > - Easy integration with more GitHub activity
> > > > >
> > > > > - Can be launched at any time because it is no need
> > > > >
> > > > > for us to share the concurrency limit with all projects.
> > > > >
> > > > > Also the concurrency limit for each project looks enough for us.
> > > > >
> > > > >
> > > > > I am wondering if we could disable Travis CI for now which function
> > > > >
> > > > > can be completely replaced with GitHub Actions?
> > > > >
> > > > >
> > > > > [1] https://github.com/apache/dubbo/actions/runs/623019397
> > > > >
> > > > > [2] https://github.com/apache/dubbo/actions/runs/620506574
> > > > >
> > > > > [3] https://github.com/apache/dubbo/actions/runs/620213136
> > > > >
> > > > > [4] https://github.com/apache/dubbo/runs/2029991040
> > > > >
> > > >
> > >
> >
>
Re: [Discuss] Disable Travis CI for apache/dubbo
Posted by Albumen Kevin <al...@apache.org>.
Hi Martin,
Actually with the help of Docker and QEMU it is not that hard!
> In short you just need to do:
> - docker run -it — rm — privileged multiarch/qemu-user-static —
> credential yes — persistent yes
> - docker run -it — rm arm64v8/ubuntu:focal bash
That's awesome. Could you please introduce it to the contribution guide[1]
to instruct contributors how to build an ARM64 env?
Yes, this is why I suggested the ARM64 build+test to be "unofficial", i.e.
> we can add it to "allow_failures" section of .travis.yml and this way it
> won't stop the merging of the PRs.
> But then the question would be whether anyone would bother to check the
> build status :-)
It seems as if nightly building is a good choice? Also, this will not block
pull request processes and we can mention it in the latest master branch.
At the moment embedded-redis is the only problem for `mvn install`.
> Is there anything else I could test on my ARM64 VM ?
The following command (you can find it in build-and-test.yml [2]) is used
to make unit tests for Dubbo in Ubuntu x86 env. You can try it on ARM64.
./mvnw --batch-mode -U -e --no-transfer-progress clean test
> -Dmaven.wagon.httpconnectionManager.ttlSeconds=120
> -Dmaven.wagon.http.retryHandler.count=5 -DskipTests=false
> -DskipIntegrationTests=false -Dcheckstyle.skip=false -Drat.skip=false
> -Dmaven.javadoc.skip=true
[1] https://github.com/apache/dubbo/blob/master/CONTRIBUTING.md
[2]
https://github.com/apache/dubbo/blob/master/.github/workflows/build-and-test.yml
Albumen
On Thu, Mar 11, 2021 at 4:03 PM Martin Tzvetanov Grigorov <
mgrigorov@apache.org> wrote:
> Hi Albumen,
>
> Please see inline.
>
> On 2021/03/10 15:13:23, Albumen Kevin <al...@apache.org> wrote:
> > Hi Martin,
> >
> > Thanks for your suggestion. I agree with you that ARM64 is an important
> > platform for us and we should adapt it in the future.
> >
> > For Dubbo, there isn't enough test for ARM64, and I think this may be a
> > problem for Dubbo to adapt ARM64 due to both Dubbo itself and
> dependencies.
> > It might not be a good choice for contributors to make sure their code
> can
> > work fine on ARM64. One is it is hard for someone to own an ARM64
>
> Actually with the help of Docker and QEMU it is not that hard!
> In short you just need to do:
> - docker run -it — rm — privileged multiarch/qemu-user-static —
> credential yes — persistent yes
> - docker run -it — rm arm64v8/ubuntu:focal bash
>
> I.e. enable QEMU/binfmt on the host (i.e. your dev machine) and then run
> any ARM64 Docker image and develop/debug whatever you need.
>
> I've explained it in more details at
> https://martin-grigorov.medium.com/building-linux-packages-for-different-cpu-architectures-with-docker-and-qemu-d29e4ebc9fa5
>
> > environment, the other one is would it cause more time to wait for a PR
> > since it passes CI / CD.
>
> Yes, this is why I suggested the ARM64 build+test to be "unofficial", i.e.
> we can add it to "allow_failures" section of .travis.yml and this way it
> won't stop the merging of the PRs.
> But then the question would be whether anyone would bother to check the
> build status :-)
>
> >
> > Currently, the integration test framework has not been adapted to Travis
> > CI, which means we can only test unit test cases for now. Also, I am sure
> > the integration test framework can also be transplanted to Travis CI.
> >
> > In my opinion, we can try to reintroduce TravisCI as a nightly tester and
> > make Dubbo more stable, but before this, we should make sure the latest
> > version source on master branch can work fine on ARM64.I am afraid that
> > there might not only embedded-redis stop Dubbo adapt ARM64.
>
> At the moment embedded-redis is the only problem for `mvn install`.
> Is there anything else I could test on my ARM64 VM ?
>
> The problem with embedded-resis library is that the official project is no
> more maintained and there are few hundreds forks of it (262,
> https://github.com/kstyrc/embedded-redis/network/members) and most of
> them again don't want to be the new official ancestor, i.e. to improve it
> and make new releases of it.
>
> >
> > Also, if Github Actions plans for ARM64 support, these things can be more
> > easier !
>
> YES! That would be the best!
>
> I'll keep you posted!
>
> Regards,
> Martin
>
> >
> > Albumen
> >
> >
> > On Wed, Mar 10, 2021 at 10:20 PM Martin Tzvetanov Grigorov <
> > mgrigorov@apache.org> wrote:
> >
> > > Hi,
> > >
> > > I see that you already dropped TravisCI -
> > >
> https://github.com/apache/dubbo/commit/cc3fb913e03424f62863c8536075be0fd04f12f2
> > >
> > > I fully agree that GitHub Actions is the better CI these days, but
> there
> > > is one thing that Travis has that the others don't: support for
> non-x86_64
> > > architectures like ARM64 and s390x.
> > > More and more server deployments are being done on ARM64 in the last
> few
> > > years.
> > > I was hoping to add a new job at TravisCI to build and test on ARM64
> but
> > > at the moment there is one stopper - embedded-redis does not support
> ARM64,
> > > because it does not have a native binary for redis-server in the jar.
> > > I've created two Pull Requests for forks which have recent releases:
> > > - https://github.com/signalapp/embedded-redis/pull/8
> > > - https://github.com/codemonstur/embedded-redis/pull/1
> > > but they are not yet reviewed and merged.
> > >
> > > Would it be OK for you to re-introduce TravisCI as unofficial CI for
> ARM64
> > > once the issue with embedded-redis is resolved ?
> > >
> > > Apache Infra plans to have a call with GitHub Actions representative -
> > >
> https://cwiki.apache.org/confluence/display/INFRA/Builds+Agenda+2021-03-11
> .
> > > I am going to ask about their plans for ARM64 support and then TravisCI
> > > could be forgotten for good!
> > >
> > > Regards,
> > > Martin
> > >
> > >
> > > On 2021/03/05 06:59:29, Albumen Kevin <al...@apache.org> wrote:
> > > > Hi community,
> > > >
> > > >
> > > > So far, we have enable two kinds of CI/CD platform , Travis CI and
> > > >
> > > > GitHub Actions, for Dubbo. GitHub actions works fine for Dubbo
> > > >
> > > > in 2.6.x[1], 2.7.x[2] and 3.x[3] versions.
> > > >
> > > > In 2.7.x and 3.x versions, both unit test and integration test[4],
> based
> > > >
> > > > on apache/dubbo-samples, are introduced to guarantee the stability
> > > >
> > > > of the snapshot version.
> > > >
> > > >
> > > > There are some benefits can be provided by GitHub Actions now:
> > > >
> > > >
> > > > - More powerful ecosystem
> > > >
> > > > - Easy integration with more GitHub activity
> > > >
> > > > - Can be launched at any time because it is no need
> > > >
> > > > for us to share the concurrency limit with all projects.
> > > >
> > > > Also the concurrency limit for each project looks enough for us.
> > > >
> > > >
> > > > I am wondering if we could disable Travis CI for now which function
> > > >
> > > > can be completely replaced with GitHub Actions?
> > > >
> > > >
> > > > [1] https://github.com/apache/dubbo/actions/runs/623019397
> > > >
> > > > [2] https://github.com/apache/dubbo/actions/runs/620506574
> > > >
> > > > [3] https://github.com/apache/dubbo/actions/runs/620213136
> > > >
> > > > [4] https://github.com/apache/dubbo/runs/2029991040
> > > >
> > >
> >
>
Re: [Discuss] Disable Travis CI for apache/dubbo
Posted by Martin Tzvetanov Grigorov <mg...@apache.org>.
Hi Albumen,
Please see inline.
On 2021/03/10 15:13:23, Albumen Kevin <al...@apache.org> wrote:
> Hi Martin,
>
> Thanks for your suggestion. I agree with you that ARM64 is an important
> platform for us and we should adapt it in the future.
>
> For Dubbo, there isn't enough test for ARM64, and I think this may be a
> problem for Dubbo to adapt ARM64 due to both Dubbo itself and dependencies.
> It might not be a good choice for contributors to make sure their code can
> work fine on ARM64. One is it is hard for someone to own an ARM64
Actually with the help of Docker and QEMU it is not that hard!
In short you just need to do:
- docker run -it — rm — privileged multiarch/qemu-user-static — credential yes — persistent yes
- docker run -it — rm arm64v8/ubuntu:focal bash
I.e. enable QEMU/binfmt on the host (i.e. your dev machine) and then run any ARM64 Docker image and develop/debug whatever you need.
I've explained it in more details at https://martin-grigorov.medium.com/building-linux-packages-for-different-cpu-architectures-with-docker-and-qemu-d29e4ebc9fa5
> environment, the other one is would it cause more time to wait for a PR
> since it passes CI / CD.
Yes, this is why I suggested the ARM64 build+test to be "unofficial", i.e. we can add it to "allow_failures" section of .travis.yml and this way it won't stop the merging of the PRs.
But then the question would be whether anyone would bother to check the build status :-)
>
> Currently, the integration test framework has not been adapted to Travis
> CI, which means we can only test unit test cases for now. Also, I am sure
> the integration test framework can also be transplanted to Travis CI.
>
> In my opinion, we can try to reintroduce TravisCI as a nightly tester and
> make Dubbo more stable, but before this, we should make sure the latest
> version source on master branch can work fine on ARM64.I am afraid that
> there might not only embedded-redis stop Dubbo adapt ARM64.
At the moment embedded-redis is the only problem for `mvn install`.
Is there anything else I could test on my ARM64 VM ?
The problem with embedded-resis library is that the official project is no more maintained and there are few hundreds forks of it (262, https://github.com/kstyrc/embedded-redis/network/members) and most of them again don't want to be the new official ancestor, i.e. to improve it and make new releases of it.
>
> Also, if Github Actions plans for ARM64 support, these things can be more
> easier !
YES! That would be the best!
I'll keep you posted!
Regards,
Martin
>
> Albumen
>
>
> On Wed, Mar 10, 2021 at 10:20 PM Martin Tzvetanov Grigorov <
> mgrigorov@apache.org> wrote:
>
> > Hi,
> >
> > I see that you already dropped TravisCI -
> > https://github.com/apache/dubbo/commit/cc3fb913e03424f62863c8536075be0fd04f12f2
> >
> > I fully agree that GitHub Actions is the better CI these days, but there
> > is one thing that Travis has that the others don't: support for non-x86_64
> > architectures like ARM64 and s390x.
> > More and more server deployments are being done on ARM64 in the last few
> > years.
> > I was hoping to add a new job at TravisCI to build and test on ARM64 but
> > at the moment there is one stopper - embedded-redis does not support ARM64,
> > because it does not have a native binary for redis-server in the jar.
> > I've created two Pull Requests for forks which have recent releases:
> > - https://github.com/signalapp/embedded-redis/pull/8
> > - https://github.com/codemonstur/embedded-redis/pull/1
> > but they are not yet reviewed and merged.
> >
> > Would it be OK for you to re-introduce TravisCI as unofficial CI for ARM64
> > once the issue with embedded-redis is resolved ?
> >
> > Apache Infra plans to have a call with GitHub Actions representative -
> > https://cwiki.apache.org/confluence/display/INFRA/Builds+Agenda+2021-03-11.
> > I am going to ask about their plans for ARM64 support and then TravisCI
> > could be forgotten for good!
> >
> > Regards,
> > Martin
> >
> >
> > On 2021/03/05 06:59:29, Albumen Kevin <al...@apache.org> wrote:
> > > Hi community,
> > >
> > >
> > > So far, we have enable two kinds of CI/CD platform , Travis CI and
> > >
> > > GitHub Actions, for Dubbo. GitHub actions works fine for Dubbo
> > >
> > > in 2.6.x[1], 2.7.x[2] and 3.x[3] versions.
> > >
> > > In 2.7.x and 3.x versions, both unit test and integration test[4], based
> > >
> > > on apache/dubbo-samples, are introduced to guarantee the stability
> > >
> > > of the snapshot version.
> > >
> > >
> > > There are some benefits can be provided by GitHub Actions now:
> > >
> > >
> > > - More powerful ecosystem
> > >
> > > - Easy integration with more GitHub activity
> > >
> > > - Can be launched at any time because it is no need
> > >
> > > for us to share the concurrency limit with all projects.
> > >
> > > Also the concurrency limit for each project looks enough for us.
> > >
> > >
> > > I am wondering if we could disable Travis CI for now which function
> > >
> > > can be completely replaced with GitHub Actions?
> > >
> > >
> > > [1] https://github.com/apache/dubbo/actions/runs/623019397
> > >
> > > [2] https://github.com/apache/dubbo/actions/runs/620506574
> > >
> > > [3] https://github.com/apache/dubbo/actions/runs/620213136
> > >
> > > [4] https://github.com/apache/dubbo/runs/2029991040
> > >
> >
>
Re: [Discuss] Disable Travis CI for apache/dubbo
Posted by Albumen Kevin <al...@apache.org>.
Hi Martin,
Thanks for your suggestion. I agree with you that ARM64 is an important
platform for us and we should adapt it in the future.
For Dubbo, there isn't enough test for ARM64, and I think this may be a
problem for Dubbo to adapt ARM64 due to both Dubbo itself and dependencies.
It might not be a good choice for contributors to make sure their code can
work fine on ARM64. One is it is hard for someone to own an ARM64
environment, the other one is would it cause more time to wait for a PR
since it passes CI / CD.
Currently, the integration test framework has not been adapted to Travis
CI, which means we can only test unit test cases for now. Also, I am sure
the integration test framework can also be transplanted to Travis CI.
In my opinion, we can try to reintroduce TravisCI as a nightly tester and
make Dubbo more stable, but before this, we should make sure the latest
version source on master branch can work fine on ARM64.I am afraid that
there might not only embedded-redis stop Dubbo adapt ARM64.
Also, if Github Actions plans for ARM64 support, these things can be more
easier !
Albumen
On Wed, Mar 10, 2021 at 10:20 PM Martin Tzvetanov Grigorov <
mgrigorov@apache.org> wrote:
> Hi,
>
> I see that you already dropped TravisCI -
> https://github.com/apache/dubbo/commit/cc3fb913e03424f62863c8536075be0fd04f12f2
>
> I fully agree that GitHub Actions is the better CI these days, but there
> is one thing that Travis has that the others don't: support for non-x86_64
> architectures like ARM64 and s390x.
> More and more server deployments are being done on ARM64 in the last few
> years.
> I was hoping to add a new job at TravisCI to build and test on ARM64 but
> at the moment there is one stopper - embedded-redis does not support ARM64,
> because it does not have a native binary for redis-server in the jar.
> I've created two Pull Requests for forks which have recent releases:
> - https://github.com/signalapp/embedded-redis/pull/8
> - https://github.com/codemonstur/embedded-redis/pull/1
> but they are not yet reviewed and merged.
>
> Would it be OK for you to re-introduce TravisCI as unofficial CI for ARM64
> once the issue with embedded-redis is resolved ?
>
> Apache Infra plans to have a call with GitHub Actions representative -
> https://cwiki.apache.org/confluence/display/INFRA/Builds+Agenda+2021-03-11.
> I am going to ask about their plans for ARM64 support and then TravisCI
> could be forgotten for good!
>
> Regards,
> Martin
>
>
> On 2021/03/05 06:59:29, Albumen Kevin <al...@apache.org> wrote:
> > Hi community,
> >
> >
> > So far, we have enable two kinds of CI/CD platform , Travis CI and
> >
> > GitHub Actions, for Dubbo. GitHub actions works fine for Dubbo
> >
> > in 2.6.x[1], 2.7.x[2] and 3.x[3] versions.
> >
> > In 2.7.x and 3.x versions, both unit test and integration test[4], based
> >
> > on apache/dubbo-samples, are introduced to guarantee the stability
> >
> > of the snapshot version.
> >
> >
> > There are some benefits can be provided by GitHub Actions now:
> >
> >
> > - More powerful ecosystem
> >
> > - Easy integration with more GitHub activity
> >
> > - Can be launched at any time because it is no need
> >
> > for us to share the concurrency limit with all projects.
> >
> > Also the concurrency limit for each project looks enough for us.
> >
> >
> > I am wondering if we could disable Travis CI for now which function
> >
> > can be completely replaced with GitHub Actions?
> >
> >
> > [1] https://github.com/apache/dubbo/actions/runs/623019397
> >
> > [2] https://github.com/apache/dubbo/actions/runs/620506574
> >
> > [3] https://github.com/apache/dubbo/actions/runs/620213136
> >
> > [4] https://github.com/apache/dubbo/runs/2029991040
> >
>
Re: [Discuss] Disable Travis CI for apache/dubbo
Posted by Martin Tzvetanov Grigorov <mg...@apache.org>.
Hi,
I see that you already dropped TravisCI - https://github.com/apache/dubbo/commit/cc3fb913e03424f62863c8536075be0fd04f12f2
I fully agree that GitHub Actions is the better CI these days, but there is one thing that Travis has that the others don't: support for non-x86_64 architectures like ARM64 and s390x.
More and more server deployments are being done on ARM64 in the last few years.
I was hoping to add a new job at TravisCI to build and test on ARM64 but at the moment there is one stopper - embedded-redis does not support ARM64, because it does not have a native binary for redis-server in the jar.
I've created two Pull Requests for forks which have recent releases:
- https://github.com/signalapp/embedded-redis/pull/8
- https://github.com/codemonstur/embedded-redis/pull/1
but they are not yet reviewed and merged.
Would it be OK for you to re-introduce TravisCI as unofficial CI for ARM64 once the issue with embedded-redis is resolved ?
Apache Infra plans to have a call with GitHub Actions representative - https://cwiki.apache.org/confluence/display/INFRA/Builds+Agenda+2021-03-11. I am going to ask about their plans for ARM64 support and then TravisCI could be forgotten for good!
Regards,
Martin
On 2021/03/05 06:59:29, Albumen Kevin <al...@apache.org> wrote:
> Hi community,
>
>
> So far, we have enable two kinds of CI/CD platform , Travis CI and
>
> GitHub Actions, for Dubbo. GitHub actions works fine for Dubbo
>
> in 2.6.x[1], 2.7.x[2] and 3.x[3] versions.
>
> In 2.7.x and 3.x versions, both unit test and integration test[4], based
>
> on apache/dubbo-samples, are introduced to guarantee the stability
>
> of the snapshot version.
>
>
> There are some benefits can be provided by GitHub Actions now:
>
>
> - More powerful ecosystem
>
> - Easy integration with more GitHub activity
>
> - Can be launched at any time because it is no need
>
> for us to share the concurrency limit with all projects.
>
> Also the concurrency limit for each project looks enough for us.
>
>
> I am wondering if we could disable Travis CI for now which function
>
> can be completely replaced with GitHub Actions?
>
>
> [1] https://github.com/apache/dubbo/actions/runs/623019397
>
> [2] https://github.com/apache/dubbo/actions/runs/620506574
>
> [3] https://github.com/apache/dubbo/actions/runs/620213136
>
> [4] https://github.com/apache/dubbo/runs/2029991040
>