Skip to content

Baking Rakudo Releases With R3

Alexey Melezhik edited this page Jun 27, 2021 · 12 revisions

Recently I've started an experimental tool called R3 - Rakudo Releases Readiness Tool.

The tool aims to help Rakudo release managers and developers prepare Rakudo releases and enable Rakudo users to file Rakudo bugs as simple and repeatable test scenarios.

In this post I am going to give a brief introduction to the tool, hoping this will spur some interests among Raku folks.


Installation is pretty simple, you'll have to install a few Raku modules supporting the tool as well a few Sparrow plugins:

# install dependencies
zef install --/test 
zef install --/test
zef install --/test

# install Bash completions
tom --completion
tomty --completion

# setup local Sparrow repo
s6 --repo-init ~/repo

# upload Sparrow plugins
git clone /tmp/sparrow-plugins
cd /tmp/sparrow-plugins
cd bash
cd ../directory
s6 --upload
s6 --index-update

Main workflow

File bugs. The main idea is filing bugs should be as simple as possible and taking minimal amount of time.

Most of the Rakudo issues could be golfed as Bash oneliners.

So, let's see some example:

Create an issue draft

tom new-issue
[repository] :: index updated from file:///root/repo/api/v1/index
issue number: 1234
tags: (use space separator for many): rc_2021_07 open
[tasks/new-issue] :: building [.tomty/1234.pl6]
[tasks/new-issue] :: stderr: ++ mkdir -p 1234
[tasks/new-issue] :: stderr: ++ echo 'cat $root_dir/task.bash'
++ echo
++ echo '$RAKUBIN -v'
++ echo
++ echo '$RAKUBIN -e '\''# some code to brake'\'''
you test is ready. run it using:
tomty 1234

An issue draft script would ask you a few questions, like an issue number which should be a GH issue number, as well as tags, which we talk about latter. Once a draft is finished you can run it against certain Rakudo version. In this example I use whateverable version of Rakudo for a certain commit:

export RAKUBIN=/tmp/whateverable/rakudo-moar/f7e9b92dc95a460d7cb36071ab0d1422caacd811/bin/raku

tomty 1234
[repository] :: index updated from file:///root/repo/api/v1/index
[1234] :: cat $root_dir/task.bash
[1234] ::
[1234] :: $RAKUBIN -v
[1234] ::
[1234] :: $RAKUBIN -e '# some code to brake'
[1234] :: Welcome to ๐‘๐š๐ค๐ฎ๐๐จโ„ข v2021.06-20-gf7e9b92dc.
[1234] :: Implementing the ๐‘๐š๐ค๐ฎโ„ข programming language v6.d.
[1234] :: Built on MoarVM version 2021.06-6-g6977d0591.

Now let's change the test a bit to reflect some real bug case:

nano 1234/task.bash

cat $root_dir/task.bash


$RAKUBIN -e 'my $s = ; $s.substr-rw(0,1) = "3"; say $s'

The test should fail for the Rakudo version 2021.04

export RAKUBIN=/tmp/whateverable/rakudo-moar/33c589c682123a9bd60ad04752bbdaa4e8beb2d0/bin/raku

tomty 1234
[repository] :: index updated from file:///root/repo/api/v1/index
[1234] :: cat $root_dir/task.bash
[1234] ::
[1234] :: $RAKUBIN -v
[1234] ::
[1234] :: $RAKUBIN -e 'my $s = ; $s.substr-rw(0,1) = "3"; say $s'
[1234] :: Welcome to Rakudo(tm) v2021.04.
[1234] :: Implementing the Raku(tm) programming language v6.d.
[1234] :: Built on MoarVM version 2021.04.
[1234] :: stderr: Too many positionals passed; expected 1 to 3 arguments but got 4
  in block  at -e line 1

[1234] :: task exit status: 1
[1234] :: task 1234 FAILED

Please follow R3 documentation on more information how to write tests.

Working with different Rakudo versions

You can set a mnemonic tomty environment to switch between different Rakudo versions, instead of exporting RAKUBIN evn variable every time:

tomty --env-edit 2021_04
/root/projects/r3tool/.tomty/env/config.2021_04.pl6 does not exit,
do you want to create it? (type Y to confirm): Y

%*ENV<RAKUBIN> = "/tmp/whateverable/rakudo-moar/33c589c682123a9bd60ad04752bbdaa4e8beb2d0/bin/raku";


Now, if you want to run a test against 2021.04 Rakudo version:

tomty --env=2021_04 1234

Working with tags

Remember tags we've set during an issue draft? Tags are just mnemonic labels allowing to run tests for certain issues.

To use tags, just add --only or --skip flag for tomty test runner. For example, to run only closed issues in the upcoming 2021.07 release:

tomty --only=rc_2021_07+closed

Follow thorough tags explanation on R3 tool doc pages to know more about tags.

The list of existing tags could be found there as well.

Tags could be very useful for release managers to get useful information before they cut releases and publish changelogs.


R3 is an experimental tool so far. I am just testing the water and see how it goes with existing Rakudo GH issues base.

If this post sparks any interest within Raku community, I'd be glad to hear possible direction for further development.

Thank you for reading.