Misc #16895: Request for cooperation: Try your applications/libraries with master branch and debug options

• Status: Open
• Assignee: -

[ko1 (Koichi Sasada)]

Summary

If you maintain a Ruby application or library, please consider testing with the Ruby master branch, including the debug build. This should be in addition to testing with all supported stable releases of Ruby.

To make this easier, we are providing Docker images and GitHub actions, as outlined below.

Details

The rapid pace of Ruby development sometimes introduces bugs, such as incorrect behaviour or unexpected incompatibilities. Despite our best efforts and testing, without your feedback, we cannot catch every issue.

Understanding how our changes impact downstream code is important feedback for the Ruby core developers. We want to know how your applications work on master.

If you encounter an error when testing with the master branch (e.g. [BUG] ... in output log), please report it. It will be very helpful.

Testing With master

Testing using the master branch (sometimes referred to as ruby-head) will make your Ruby scripts ready for the next Ruby version. It also helps us catch incompatibilities as we change and evolve Ruby's public interface.

Testing With Debug Build

Testing with the master branch debug build enables many assertions within the Ruby interpreter.

These assertions can detect incorrect usage of the C extensions, and also bugs in the interpreter when running your program.

These assertions have an impact on the performance of the interpreter.

To compile a debug build, refer the later section titled "Building With Debug Mode".

Continuous Integration With master

Building Ruby for your own testing environment can be difficult, so we are providing two convenient ways to use the master branch in your existing testing pipeline:

• Docker Images
• Github Action

Docker Images

The rubylang docker repository provides images for various Ruby versions, including nightly builds of master with and without debug assertions"

• Nightly built master: rubylang/ruby:master-nightly-bionic
• Nightly debug built master: rubylang/ruby:master-debug-nightly-bionic

Here is an example Dockerfile:

FROM rubylang/ruby:master-nightly-bionic

Then to build:

$ docker build .
Sending build context to Docker daemon  2.048kB
Step 1/1 : FROM rubylang/ruby:master-nightly-bionic
master-nightly-bionic: Pulling from rubylang/ruby
...
Status: Downloaded newer image for rubylang/ruby:master-nightly-bionic
 ---> 059d367a8fbd
Successfully built 059d367a8fbd

GitHub Action

The GitHub Action to setup Ruby provides both ruby-head and ruby-debug builds.

Here is an example workflow to test on all Ruby stable releases, including ruby-head and ruby-debug:

name: Development
on: [push]
jobs:
  test:
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu]
        ruby: [2.5, 2.6, 2.7, head, debug]

    runs-on: ${{ matrix.os }}-latest
    continue-on-error: ${{ matrix.ruby == 'head' || matrix.ruby == 'debug' }}
    steps:
    - uses: actions/checkout@v2
    - uses: ruby/setup-ruby@v1
      with:
        ruby-version: ${{ matrix.ruby }}

    - run: bundle install
    - run: bundle exec rake

See the documentation for more details on how to use this action.

Building With Debug Mode

To create a debug build of Ruby, execute the following commands:

$ git clone https://github.com/ruby/ruby.git
$ cd ruby
$ autoconf
$ cppflags=-DRUBY_DEBUG=1 ./configure --prefix=$HOME/.rubies/ruby-debug
$ make install

If you are using chruby, you can switch to the above build:

$ chruby ruby-debug

You can find more details to build Ruby master in the README.

Acknowledgement

We thank @mrkn (Kenta Murata) for the Docker image, @Eregon (Benoit Daloze) for the GitHub Action, and @ioquatix (Samuel Williams) for reviewing this announcement.

[ko1 (Koichi Sasada)]

• Subject changed from Request for cooperation: Try your applications/libraries with master and master-debug build to Request for cooperation: Try your applications/libraries with master branch and debug options
• Description updated (diff)

Samuel and Eregon rewrote a description. Thank you!

[ioquatix (Samuel Williams)]

• Description updated (diff)

Updated from latest edits.

[ioquatix (Samuel Williams)]

• Description updated (diff)

Make first paragraph read a bit better.

[rubyFeedback (robert heiler)]

As I got older (it has been almost 20 years now since I have
been using ruby, and I feel physically older too compared to
the more young-version of me back in the days), my focus has
shifted a bit. I was super-experimental when I was younger.

Nowadays I try to stay with stable ruby releases whenever
possible. So the xmas-release is usually when I switch; I
do tend to switch as quickly as possible, to avoid any
legacy-drag that we had from e. g. ruby 1.8.x to 1.9.x to
2.x and beyond. I am kind of like "an early adopter of
stable ruby", if that makes sense. :D

I can still find some issues here and there and report it.
Testing unstable is a bit of an issue and hassle, though.

I wrote a lot of ruby scripts over the years, and ruby
is used to maintain my whole linux system (I compile from
source whenever possible); so getting the new git release
of ruby is as simple as doing "ry ruby --gitty" for me.
That will download the latest git sources, re-package
them into .tar.xz and put it into $SRC_DIR/ruby/. I can
even automatically compile it too. So this is actually
the simple part.

The bigger issue is time investment, and forgetting it.
I kind of adjusted mentally to be lazy, so I download
the latest ruby on xmas and then keep on using it,
until the next xmas. So I rarely get to test new features,
unless they are interesting.

I don't have a good alternative model. Would be interesting
if we could have ruby so modular that there be tons of
ruby dialects, and we could test each dialect in the "middle
of the year", just recompiling parts of ruby that would be
affected (e. g. like when pattern matching was added. Imagine
if we could have a toggle for all of ruby behaviour, a bit
like we can specify the linux kernel).