Misc #16895
openRequest for cooperation: Try your applications/libraries with master branch and debug options
Description
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.
Updated by ko1 (Koichi Sasada) over 4 years ago
- 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!
Updated by ioquatix (Samuel Williams) over 4 years ago
- Description updated (diff)
Updated from latest edits.
Updated by ioquatix (Samuel Williams) over 4 years ago
- Description updated (diff)
Make first paragraph read a bit better.
Updated by rubyFeedback (robert heiler) over 1 year ago
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).