Baking Rakudo Releases With R3
Clone this wiki locally
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 https://github.com/melezhik/Sparrow6.git zef install --/test https://github.com/melezhik/Tomtit.git zef install --/test https://github.com/melezhik/Tomty.git # install Bash completions tom --completion tomty --completion # setup local Sparrow repo s6 --repo-init ~/repo # upload Sparrow plugins git clone https://github.com/melezhik/sparrow-plugins /tmp/sparrow-plugins cd /tmp/sparrow-plugins cd bash cd ../directory s6 --upload s6 --index-update
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:
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 ================================================== [https://github.com/rakudo/rakudo/issues/1234] ==================================================  :: cat $root_dir/task.bash  ::  :: $RAKUBIN -v  ::  :: $RAKUBIN -e '# some code to brake'  :: Welcome to 𝐑𝐚𝐤𝐮𝐝𝐨™ v2021.06-20-gf7e9b92dc.  :: Implementing the 𝐑𝐚𝐤𝐮™ programming language v6.d.  :: 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 -v $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 ================================================== [https://github.com/rakudo/rakudo/issues/1234] ==================================================  :: cat $root_dir/task.bash  ::  :: $RAKUBIN -v  ::  :: $RAKUBIN -e 'my $s = ; $s.substr-rw(0,1) = "3"; say $s'  :: Welcome to Rakudo(tm) v2021.04.  :: Implementing the Raku(tm) programming language v6.d.  :: Built on MoarVM version 2021.04.  :: stderr: Too many positionals passed; expected 1 to 3 arguments but got 4 in block at -e line 1  :: task exit status: 1  :: task 1234 FAILED
Please follow R3 documentation on more information how to write tests.
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
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
--skip flag for tomty test runner. For example, to run only closed issues in the upcoming 2021.07 release:
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.