ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: jaruga@redhat.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:95748] [Ruby master Misc#16234] Enabling ARM 64/32-bit cases by Drone CI
Date: Thu, 07 Nov 2019 20:43:49 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-82565.20191107204348.c859a90134d31f7c@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-16234.20191003184140@ruby-lang.org

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


jaruga (Jun Aruga) wrote:
> Shall we add debug code to investigate a random "make install" error on arm64 to `.travis.yml`?
> At least we can remove current existing debugging code for Mac OSX after "make install" in `.travis.yml`.
> 
> This pull-request is the suggestion.
> https://github.com/ruby/ruby/pull/2642

For the permission issue `cp: cannot create regular file '../../.ext/common/json.rb': Permission denied` in `make install`, I found a clue.

I did run following commands in both Travis x86_64 and arm32.
The issue is happening in `ext/*/Makefile` files. `COPY` and `V` argument are used in the `Makefile` files.

```
ls -l --full-time -t $(pwd)/.ext/.timestamp/.RUBYCOMMONDIR.time $(pwd)/.ext/common/*.rb || true
make --debug --trace V=1 COPY='pwd; (ls -l --full-time -t ../../.ext/.timestamp/.RUBYCOMMONDIR.time ../../.ext/common/*.rb || true); cp -v' install
```

Then here is the result in Travis x86_64.
The `.ext/.timestamp/.RUBYCOMMONDIR.time` file has to be older than other `.ext/common/*.rb` files.
Because when `.RUBYCOMMONDIR.time` file is newer than a `.ext/common/foo.rb` file, `COPY` (= `cp` as default) from `ext/json/lib/json.rb` to `.ext/common/foo.rb` is executed in `ext/foo/Makefile`. But the destination `.ext/common/foo.rb` file permission is `444` (read only `-r--r--r--`), the copy is failed. When `COPY='cp -f'`, it is succeeded.

```
$ ls -l --full-time -t $(pwd)/.ext/.timestamp/.RUBYCOMMONDIR.time $(pwd)/.ext/common/*.rb
Thu Nov  7 19:56:50 UTC 2019
-r--r--r-- 1 travis travis  2894 2019-11-07 19:56:48.937972000 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/digest.rb
-r--r--r-- 1 travis travis 16562 2019-11-07 19:56:48.901990000 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/pathname.rb
-r--r--r-- 1 travis travis  2494 2019-11-07 19:56:46.523179999 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/ripper.rb
-r--r--r-- 1 travis travis 44702 2019-11-07 19:56:46.399242000 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/socket.rb
-r--r--r-- 1 travis travis  1722 2019-11-07 19:56:46.323280000 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/fiddle.rb
-r--r--r-- 1 travis travis  6706 2019-11-07 19:56:46.095393999 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/monitor.rb
-r--r--r-- 1 travis travis  1036 2019-11-07 19:56:46.027427999 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/date.rb
-r--r--r-- 1 travis travis    24 2019-11-07 19:56:45.807538000 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/bigdecimal.rb
-r--r--r-- 1 travis travis   368 2019-11-07 19:56:45.507688000 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/coverage.rb
-r--r--r-- 1 travis travis  1809 2019-11-07 19:56:45.491696000 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/json.rb
-r--r--r-- 1 travis travis   469 2019-11-07 19:56:45.247817999 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/openssl.rb
-r--r--r-- 1 travis travis  5861 2019-11-07 19:56:44.947967999 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/kconv.rb
-r--r--r-- 1 travis travis 21533 2019-11-07 19:56:44.947967999 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/psych.rb
-r--r--r-- 1 travis travis  2217 2019-11-07 19:56:44.452216000 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/expect.rb
-rw-rw-r-- 1 travis travis     0 2019-11-07 19:56:44.364259999 +0000 /home/travis/build/junaruga/ruby/build/.ext/.timestamp/.RUBYCOMMONDIR.time
```

In Travis arm64, 

Some `.ext/common/*.rb` files are newer than `.ext/.timestamp/.RUBYCOMMONDIR.time` file.
That is the reason of the error.
But the problem is why some `.ext/common/*.rb` files are newer than `.ext/.timestamp/.RUBYCOMMONDIR.time` file.
This situation does not happen at the 1st CI build by a commit changing the `.travis.yml`. This happens after 2nd CI build by a commit without changing `.travis.yml`.


```
$ ls -l --full-time -t $(pwd)/.ext/.timestamp/.RUBYCOMMONDIR.time $(pwd)/.ext/common/*.rb
Thu Nov  7 19:59:01 UTC 2019
-r--r--r-- 1 travis travis  5861 2019-11-07 19:58:46.029993853 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/kconv.rb
-r--r--r-- 1 travis travis 16562 2019-11-07 19:58:45.737996933 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/pathname.rb
-r--r--r-- 1 travis travis   469 2019-11-07 19:58:44.746007400 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/openssl.rb
-r--r--r-- 1 travis travis 44702 2019-11-07 19:58:43.606019428 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/socket.rb
-r--r--r-- 1 travis travis  2494 2019-11-07 19:58:43.530020230 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/ripper.rb
-r--r--r-- 1 travis travis 21533 2019-11-07 19:58:43.470020863 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/psych.rb
-r--r--r-- 1 travis travis  1036 2019-11-07 19:58:43.294022720 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/date.rb
-r--r--r-- 1 travis travis  1722 2019-11-07 19:58:42.994025885 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/fiddle.rb
-r--r--r-- 1 travis travis    24 2019-11-07 19:58:42.422031920 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/bigdecimal.rb
-r--r--r-- 1 travis travis  2894 2019-11-07 19:58:42.370032469 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/digest.rb
-rw-r--r-- 1 travis travis     0 2019-11-07 19:58:42.326032933 +0000 /home/travis/build/junaruga/ruby/build/.ext/.timestamp/.RUBYCOMMONDIR.time
-r--r--r-- 1 travis travis  2217 2019-11-07 19:58:42.174034537 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/expect.rb
-r--r--r-- 1 travis travis  6706 2019-11-07 19:58:42.130035001 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/monitor.rb
-r--r--r-- 1 travis travis   368 2019-11-07 19:58:41.638040192 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/coverage.rb
-r--r--r-- 1 travis travis  1809 2019-11-07 19:58:41.266044117 +0000 /home/travis/build/junaruga/ruby/build/.ext/common/json.rb
```

* 1st CI build (arm64): ok: https://travis-ci.org/ruby/ruby/jobs/608915893#L2361
* 2nd CI build (arm64) with empty commit: error: https://travis-ci.org/ruby/ruby/jobs/608925381#L2351




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

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

  parent reply	other threads:[~2019-11-07 20:43 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-16234.20191003184140@ruby-lang.org>
2019-10-03 18:41 ` [ruby-core:95201] [Ruby master Misc#16234] Enabling ARM 64/32-bit cases by Drone CI jaruga
2019-10-03 19:20 ` [ruby-core:95203] " jaruga
2019-10-03 19:24 ` [ruby-core:95204] " takashikkbn
2019-10-03 21:14 ` [ruby-core:95206] " takashikkbn
2019-10-03 22:48 ` [ruby-core:95209] " jaruga
2019-10-03 23:56 ` [ruby-core:95212] " mame
2019-10-07 22:30 ` [ruby-core:95270] " jaruga
2019-10-07 22:41 ` [ruby-core:95271] " jaruga
2019-10-08  2:17 ` [ruby-core:95275] " takashikkbn
2019-10-08 11:25 ` [ruby-core:95277] " jaruga
2019-10-08 13:33 ` [ruby-core:95278] " takashikkbn
2019-10-08 14:56 ` [ruby-core:95279] " jaruga
2019-10-15 20:16 ` [ruby-core:95346] " jaruga
2019-11-04 14:31 ` [ruby-core:95667] " jaruga
2019-11-06 17:11 ` [ruby-core:95725] " jaruga
2019-11-06 19:09 ` [ruby-core:95726] " jaruga
2019-11-06 19:26 ` [ruby-core:95727] " jaruga
2019-11-06 22:07 ` [ruby-core:95729] " eregontp
2019-11-06 22:08 ` [ruby-core:95730] " eregontp
2019-11-06 22:12 ` [ruby-core:95731] " eregontp
2019-11-07 14:37 ` [ruby-core:95742] " jaruga
2019-11-07 20:43 ` jaruga [this message]
2019-11-08 18:09 ` [ruby-core:95763] " jaruga
2019-11-11 17:31 ` [ruby-core:95796] " jaruga
2019-11-12 18:05 ` [ruby-core:95818] " jaruga
2019-11-21 15:52 ` [ruby-core:95906] " jaruga

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-82565.20191107204348.c859a90134d31f7c@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).