Issue #16234 has been updated by jaruga (Jun Aruga).


> That's a nice feature. Possibly we can drop Drone to simplify the situation if we can give up arm32 support (not sure).

Yeah, it's a nice feature. We can drop Drone CI, if Travis works well with "arch: arm64". We might be able to run arm32 (ARM 32-bit) using multilib on arm64 (ARM 64-bit) on Travis too, as we have already been running i686 (Intel 32-bit) case on x86_64 (Intel 64-bit) on Travis.
I am still thinking about the possibility to check Solaris and FreeBSD and etc case at a pull-request timing with SSH Runner on Drone CI.


> if we can give up arm32 support (not sure).

I think arm32 is still popular for users, at least more than i686 (Intel 32-bit).

Because of the supported architectures for Linux distributions, Raspberry_Pi and the market share. Let me explain it one by one.


### Linux distributions

For example Ubuntu is supporting arm32, providing the container image.

> https://hub.docker.com/_/ubuntu
> Supported architectures: (more info)
> amd64, arm32v7, arm64v8, i386, ppc64le, s390x

Fedora project is supporting arm32 too.

> https://hub.docker.com/_/fedora
> Supported architectures: (more info)
> amd64, arm32v7, arm64v8, ppc64le, s390x


### Raspberry Pi

> https://en.wikipedia.org/wiki/Raspberry_Pi
> https://www.raspberrypi.org/blog/raspberry-pi-2-on-sale/

According to the Raspberry Pi wikipedia page, the Raspberry Pi version 1.1 is the last model for 32-bit, and the announcement was 5 August 2015.

When I discussed about use cases of ARM 32-bit in Fedora project, someone said "the Raspberry Pi performs quite badly as a 64-bit device for the moment, I've used it with Fedora armv7hl instead of aarch64." according to the email thread: https://lists.fedoraproject.org/archives/list/devel / lists.fedoraproject.org/message/Q742AVVBR6W6RTSVRYDSSGVKFOM3XTEF/


### Market share

In 2017, armv7 (ARM 32-bit) was 98.1% in total Android device market share.
https://android.stackexchange.com/questions/186334/what-percentage-of-android-devices-runs-on-x86-architecture/202022#202022

I would like to hear other people's opinion about how much ARM 32-bit CPU is used currently.
I assume people working at ARM are in Ruby project, and they have current market share data about ARM 32-bit.


> I'm neutral about introducing the Starlark. While it simplifies duplications in the build config, obviously current maintainers are not familiar with the language. Other CI systems are achieving the same thing by either YAML alias or a built-in matrix syntax. Doesn't Drone support any of them?

You are right. The Starlark way is not great for Ruby project. I would close the pull-request.
I have not investigated about the YAML alias in Drone CI yet, and I could not find the matrix syntax in it.


----------------------------------------
Misc #16234: Enabling ARM 64/32-bit cases by Drone CI
https://bugs.ruby-lang.org/issues/16234#change-81953

* Author: jaruga (Jun Aruga)
* Status: Closed
* Priority: Normal
* Assignee: 
----------------------------------------
Currently ruby project has 4 CIs on GitHub.

1. Travis CI: linux cases with flags and compilers.
2. GitHub Actions: macros, windows, ubuntu
3. Wercker: Ruby JIT cases
4. Appveyor: windows

I like to suggest 5th CI: Drone CI for ARM 64/32-bit cases.
Drone CI supports native the ARM 64/32 bit environments.
Have you used Drone CI?

I tried to use both Drone CI and Shippable CI supporting ARM.
My impression for Drone CI is quite good. Great user experience and user interface.
Shippable CI was not so good for some reasons.

Drone CI have not only linux ARM 64/32 bit environments on DockerRunner mode (= using container for CI like Wercker), but also freebsd, netbsd, openbsd, dragonfly (?) and solaris environments on ExecRunner (= maybe running commands directly without container) mode according to the following documents.
* https://exec-runner.docs.drone.io/configuration/platform/
* https://docker-runner.docs.drone.io/configuration/platform/

Is it exciting isn't it?
We can check ARM issue at a pull-request timing.

Here is the example. The content is almost same with wercker.yml except JIT option.
"ruby/3" is failed on the latest master branch, but "ruby/2" arm64 case is succeeded on old master branch.
https://cloud.drone.io/junaruga/ruby/3
https://github.com/junaruga/ruby/blob/feature/ci-arm/.drone.yml
https://cloud.drone.io/junaruga/ruby/2
Here is the pull-request as an example.
https://github.com/ruby/ruby/pull/2520

.drone.yml is the file to manage the CI cases.
But when you see most of the YAML parts between ARM 64-bit and 32-bit cases in .drone.yml is same. In case of .traivs.yml, we are using YAML anchor (&) and reference (*) feature effectively. But in case of .drone.yml I am not sure we can still use it beyond the "---" separator. Luckily Drone CI started providing the alternative .drone.star file by Starlark language.
https://docs.drone.io/starlark/overview/
https://blog.drone.io/create-pipelines-using-starlark/

Enabling Drone CI is quite simple.
Just go to https://drone.io/ , then register and enable target repository. UI is quite good.

Pros

* We can check ARM 64/32-bit cases, and possibly freebsd and solaris cases too.
* It's for free.
* Each developer can debug ARM cases on their forked repository.
* Customize easily. I see .travis.yml is used effectively.

Cons

* Have to manage additonal file .drone.yml or .drone.star.

But first, I want to ask you. Are you interested in using Drone CI for Ruby project?




-- 
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>