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 < [email protected]> wrote: > Hi Albumen, > > Please see inline. > > On 2021/03/10 15:13:23, Albumen Kevin <[email protected]> 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 < > > [email protected]> 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 <[email protected]> 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 > > > > > > > > > >
