From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 4989D1F4BD for ; Mon, 7 Oct 2019 22:30:57 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id A01A8120A18; Tue, 8 Oct 2019 07:30:48 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id A9F49120A17 for ; Tue, 8 Oct 2019 07:30:46 +0900 (JST) Received: by filter0109p3las1.sendgrid.net with SMTP id filter0109p3las1-26133-5D9BBC99-71 2019-10-07 22:30:49.772730546 +0000 UTC m=+359148.964050826 Received: from herokuapp.com (unknown [54.158.92.1]) by ismtpd0065p1mdw1.sendgrid.net (SG) with ESMTP id 5WGxyqAjTKim8_VpVs5eQQ for ; Mon, 07 Oct 2019 22:30:49.574 +0000 (UTC) Date: Mon, 07 Oct 2019 22:30:49 +0000 (UTC) From: jaruga@redhat.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 70857 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16234 X-Redmine-Issue-Author: jaruga X-Redmine-Sender: jaruga X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?yXpFNqRr1dEY0snEQ6vUpjORBmm3WV3CBkaa8tOjsKkOtyQUmdfJM3h3a0P91V?= =?us-ascii?Q?h5AIwV4mMkTqm1GJnuXeGHN=2Fhb4TI2KRgyWO2FC?= =?us-ascii?Q?Sh2cs+lzr1WiLvwtlwpMjrAXWBMppFgdrRRKAcY?= =?us-ascii?Q?jG0RMUhsG0qvFCcx1w8BWM4wAH9h4zorkYl47nY?= =?us-ascii?Q?7YrydgkefHfA5Xv19wjiE1FVqJGWCVJnDAw=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 95270 Subject: [ruby-core:95270] [Ruby master Misc#16234] Enabling ARM 64/32-bit cases by Drone CI X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #16234 has been updated by jaruga (Jun Aruga). There is "Azure pipelines" CI too. > BTW, I feel that we have too many CIs currently. Too many CIs brings too many notifications. Their formats are not uniform, which makes it harder to grasp the status. Agree. Many CIs. Is there no duplicated CI cases between them, right? For example, it seems that windows case is in GitHub Actions, Appveyor and Azure pipelines. > I know that they have pros and cons, so it would be difficult to integrate all of them into one CI. (If Drone CI can do it, it is really great.) > It would be great if anyone creates a "curation" site to gather all the CI results into one site, like RubyCI. One possibility of Drone CI that can integrate some of them into one CI is using SSH Runner. For example, it might be possible integrate RubyCI's Solaris server to Drone CI using SSH Runner. https://ssh-runner.docs.drone.io/configuration/ When I did chat people in Drone CI on the public chatroom (very useful!), they advised it to me. https://ssh-runner.docs.drone.io/support/ I was told Exec Runner was not available for the cloud. ;< Instead, they recommend using SSH Runner for the purpose. By the way, I also sent new PR to replace .drone.yml with .drone.star . It's just refactoring. The content is same. https://github.com/ruby/ruby/pull/2536 Maybe the owner of the ruby/ruby can see Setting - Main - Configuration - .drone.yml at https://cloud.drone.io/ruby/ruby/settings page. They can rename the .drone.yml to .drone.star in the page before merging the PR. Then the .drone.star becomes available to run for ruby/ruby repository. Let me introduce Starlark (.star) and tips about .drone.star that I investigated today. Here is the Starlark language information. It's very similar with Python syntax. https://docs.bazel.build/versions/master/skylark/language.html I installed below implementation on Go lang. https://github.com/google/starlark-go/ Here is drone command line tool to check the result of .drone.star on local. https://github.com/drone/drone-cli Follwoing command outputs json format from .drone.star on current directory. ``` $ drone starlark --stdout --format=false ``` Following command outputs YAML format from .drone.star on current directory. ``` $ drone starlark --stdout ``` I heard .drone.star was converted to YAML format internally in Drone CI, then the YAML data was executed in the public chat room. Drone CI Bug Tracking System. https://discourse.drone.io ---------------------------------------- Misc #16234: Enabling ARM 64/32-bit cases by Drone CI https://bugs.ruby-lang.org/issues/16234#change-81946 * 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/