Issue #22001 has been updated by st0012 (Stan Lo). As discussed in person today, let's see if we can configure TruffleRuby runs in a separate yml file so we can [disable the workflow](https://docs.github.com/en/actions/how-tos/manage-workflow-runs/disable-and-...) when it fails without changing code. This way we can further reduce the work gem maintainers need to do to disable/re-enable TruffleRuby CI. ---------------------------------------- Misc #22001: Adding TruffleRuby in the CI of all default & bundled gems https://bugs.ruby-lang.org/issues/22001#change-117083 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- I would like to add TruffleRuby (i.e. `ruby-version: truffleruby`, the latest release for improved stability) in the CI of all default & bundled gems. I'm tracking the progress in https://github.com/truffleruby/truffleruby/issues/2644. The reason is default & bundled gems are more likely to depend on CRuby internals or CRuby specifics, and have a very large blast readius, and so adding TruffleRuby there would help to avoid such gems breaking unknowingly on TruffleRuby, which has happened a number of times in the past (and similarly on JRuby). The concrete issue is that for some gems without active maintainers (such as in #21922 and more) it can take a (sometimes very) long time to merge the PR adding TruffleRuby in CI. How can we solve this? I also don't want TruffleRuby being in CI to be any kind of burden, so if there is any issue with it more frequent than other Ruby versions in CI, it seems fair to remove it or use `continue-on-error: true` or just ignore the failure. If removing, my only request would be if possible to include `@eregon` in the PR description removing the job so I can take a look. To help keeping CIs green I use [truffleruby-gem-tracker](https://github.com/truffleruby/truffleruby-gem-tracker) and I try to check it regularly to fix any failure. -- https://bugs.ruby-lang.org/