From: matz@... Date: 2021-04-06T04:57:59+00:00 Subject: [ruby-core:103248] [Ruby master Misc#17720] Cirrus CI to check non-x86_64 architecture cases by own machines Issue #17720 has been updated by matz (Yukihiro Matsumoto). I approve @jaruga to be a member of the core committers. Matz. ---------------------------------------- Misc #17720: Cirrus CI to check non-x86_64 architecture cases by own machines https://bugs.ruby-lang.org/issues/17720#change-91330 * Author: jaruga (Jun Aruga) * Status: Assigned * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Hello! This ticket is related to the tickets #16234 #16360. But I opened a new ticket because it is related to general non-x86_64 architecture CI cases. I have a suggestion. I see the `.travis.yml` was removed [1], and I also saw another open source project remove their `.travis.yml` because they could not get the credits to continue to run Travis [2]. I feel Travis is not really a possible option for every open source project for now. While we have RubyCI, I think we still have a motivation to run a CI on non-x86_64 architectures at a pull-request timing. So, I investigated alternative CI. When checking GitHub Actions, I do not feel it will happen soon on GitHub Actions [3]. Then I found an interesting CI called "Cirrus CI", that might enable us to run CI on non-x86_64 architectures such as Mac M1 (arm) ppc64le and s390x beyond the cloud. Cirrus CI has 2 types of features: "cloud" and "persistent workers". I see the Cirrus CI "cloud" feature has been used in the QEMU and podman projects [4][5]. It has a unique freeBSD host. However the remarkable feature for the Ruby project is the "persistent workers" [6] announced a few months ago, that is beyond the cloud. Because this feature enables us to use our own machines as a CI running host. You can see the examples running the CI with the machines such as Mac M1, iPhone, ppc64le and s390x on the page [6]. Maybe the used machine does not even have the global static IP. You can see other articles [7][8] too. I can see some benefits to start Cirrus CI for the Ruby project. * Possibly we can check Mac M1 (arm), ppc64le, s390x cases using machines used in RubyCI [9] and someone's machine such as @ReiOdaira's ppc64le/s390x machines at the pull-request timing. * When we face the CI issue, we can login to the machine and use the interactive debugging tool such as gdb to fix it. * The config file is YAML format and it has the matrix feature [10]. We are familiar with the YAML and matrix. What do you think? Positive or negative? Thank you. [1] ruby removed .travis.yml: https://github.com/ruby/ruby/commit/6b978d542704a5614af5e9375c4b31b8d2618652 [2] simde removed .travis.yml: https://github.com/simd-everywhere/simde/commit/17a27e7f2c3114225899f2ace14010cbbb2139b5 [3] GitHub Actions and ppc64le: https://github.community/t/self-hosted-runner-on-ppc64el-architecture/155337 [4] QEMU: https://gitlab.com/qemu-project/qemu/-/blob/master/.cirrus.yml [5] Podman: https://github.com/containers/podman/blob/master/.cirrus.yml [6] The issue ticket of Persistent Workers: https://github.com/cirruslabs/cirrus-ci-docs/issues/263#issuecomment-746900845 [7] Persistent Workers blog: https://medium.com/cirruslabs/announcing-public-beta-of-cirrus-ci-persistent-workers-7327a38004be [8] Persistent Workers guide: https://cirrus-ci.org/guide/persistent-workers/ [9] RubyCI: https://rubyci.org/ [10] Cirrus CI matrix feature: https://cirrus-ci.org/guide/writing-tasks/#matrix-modification -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>