bazel-contrib / bazel-contrib/rules_ruby
JRuby debugging support or documentation
- Dominant language
- Starlark
- Stars
- 50
- Forks
- 22
- Avg merge
- 9d 23h
- Merged PRs (30d)
- 5
Description
Filing an issue track and discuss JRuby debugging either interactively with a gem like `pry` or with a remote client as suggested in [known issues](https://github.com/bazel-contrib/rules_ruby?tab=readme-ov-file#known-issues).
bazel version: `bazel 7.1.0- (@non-git)`
Jruby version: `jruby 9.4.13.0 (3.1.4) 2025-06-10 9938a3461f OpenJDK 64-Bit Server VM 11.0.23+0-adhoc..source on 11.0.23+0-adhoc..source +jit [x86_64-linux]`
My attempts to get interactive JRuby debugging with bazel so far have not worked and I am wondering if anyone else has had any success. Either a simple `pry` session or a remote client would be great, so far I have not found any solution.
Attempts:
1) Use `--run_under` with extra jruby args `--debug -S rdebug` as recommended on [JRuby docs](https://github.com/jruby/jruby/wiki/UsingTheJRubyDebugger).
```
# .bazelrc
test:rdebug --run_under="@ruby//:ruby --debug -S rdebug"
run:rdebug --run_under="@ruby//:ruby --debug -S rdebug"
> bazel run --config rdebug //...
SyntaxError in ...XXX_rb.sh:5: syntax error, unexpected local variable or method
set -uo pipefail; f=bazel_tools/tools/bash/run...
^~~~~~~~
```
I believe this fails because rb_binary and rb_test produce a shell script as the executable, and `jruby --debug -S rdebug` obviously cannot execute a shell script.
2) Directly use `pry` or `pry-remote` in source file and use `bazel run` instead of `bazel test`, which supposedly allows STDIN access as a workaround.
In ruby file:
```
require 'pry'
require 'pry-remote'
# anywhere in test file
binding.pry
binding.remote_pry
> bazel run //...
exec ${PAGER:-/usr/bin/less} "$0" || exit 1
Executing tests from //XXX
-----------------------------------------------------------------------------
Started with run options --seed 51274
SomeTest
test_xxx SKIP (2.14s)
# hangs here and nothing else happens
```
In this case, it appears the `binding.pry` is successfully halting the program, however there is no ability to interact with pry session.
Contributor guide
Assessment
This issue has not been assessed yet.