Hi Albumen, Please see inline.
On 2021/03/10 15:13:23, Albumen Kevin <album...@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 < > mgrigo...@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 <album...@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 > > > > > >
