Handle exec error

[headius]

Apparently this exec errors when the subprocess fails rather than returning an error code. This causes the whole setup process to terminate. This patch catches the error and uses that to indicate failure to launch.

Hopefully will address the issue in ruby/jruby-dev-builder#10 (comment)

[eregon]

The docs are at https://github.com/actions/toolkit/tree/main/packages/exec
Could you try https://github.com/actions/toolkit/blob/d9347d4ab99fd507c0b9104b2cf79fb44fcc827d/packages/exec/src/interfaces.ts#L27-L28 ?

The try/catch works, but might hide other issues which we shouldn't necessarily ignore (e.g. passing bad arguments to that function).

[headius]

@eregon I'll try. I don't know the syntax for that but I'll figure it out.

[headius]

@eregon In theory the latest attempt should do it. TruffleRuby failure seems very much unrelated.

[headius]

Sorry about the churn here but without a better way to test this we're forced to iterate in the wild. Does GHA have any test instance or harness that can be used off the grid?

[eregon]

There is https://github.com/nektos/act but I haven't tried it.
One idea is we should have tried passing an invalid flag instead of ruby --version in the original PR to simulate the JRuby 10 case of process exiting with non-zero.

[headius]

@eregon I pushed a throw-away commit to test with a bad flag.

[eregon]

It seems to hang on Windows, see https://github.com/ruby/setup-ruby/actions/runs/13841525436/job/38730124830?pr=722 and https://github.com/ruby/setup-ruby/actions/runs/13841525436/job/38730135071?pr=722
It uses D:\jruby-head\bin\ruby.bat there, the .bat (EDIT:) I think that shouldn't be used, there is an executable from jruby-launcher IIRC.

[headius]

Is there something else the JRuby install on Windows does to make it runnable? I literally used the same code you had for the final version print-out and it did not hang there.

[eregon]

Yeah, so it seems a JRuby 10 + Windows bug.
JRuby 9 worked fine, and also used the .bat: https://github.com/ruby/setup-ruby/actions/runs/13820766951/job/38665461620#step:3:38

[eregon]

I think at this point we won't find a quick fix, it sounds like a difference between JRuby 9 and 10.
To avoid breaking existing users of jruby-head, I suggest to revert ruby/jruby-dev-builder#10 and trigger a build there. I let you do it, you should already have the permissions for that.

[headius]

@eregon The bat file is not the preferred way to launch on Windows and may introduce other problems. Why is it running with the bat file?

[headius]

We are looking into the --version hang on Windows.

[eregon]

I don't know, that may be an issue of exec.exec, or the builds of JRuby on Windows.
Example build of jruby-head and relevant line about .bat: https://github.com/ruby/jruby-dev-builder/actions/runs/13839648355/job/38723593911#step:10:6

Example build of a jruby release build: https://github.com/ruby/ruby-builder/actions/runs/13047231536/job/36399785028#step:9:7

I misremembered about jruby-launcher, that's only done for releases and on linux/macOS, e.g.
https://github.com/ruby/ruby-builder/actions/runs/13047231536/job/36399786116#step:19:24

[headius]

JRuby's dist (tar.gz and zip)includes a jruby.exe in bin out of the box.

We cannot reproduce the hang on a local Windows system.

[eregon]

See jruby/jruby#6042 on the reasoning for adding jruby.bat

[headius]

I will try something here as a test. No way to verify these things locally and it does not hang with any combination of 10 build and ruby.bat for us.

[eregon]

Feel free to try changing https://github.com/ruby/jruby-dev-builder/blob/a4cdaa60a48c4bfb237f6071f950752ec59ec6e0/.github/workflows/build.yml#L129-L130 since anyway jruby-head on Windows is broken.
Maybe the .bat is no longer needed for some reason?
Possibly related to the 64-bit vs 32-bit thing mentioned in jruby/jruby#6042

I'll log off now, it's quite late here.
If you want to unbreak jruby-head for existing setup-ruby users, the easiest way is #722 (comment)

[headius]

I will be forced to undo the 9.4 to 10 change if you will be unable to merge anything further here, but I will also be unable to fix anything here.

[headius]

Switching to the exe did not help either so it's not that. We are trying to find a way to reproduce the issue on Windows. I will keep trying things here but will revert the jruby-head change before giving up for the day.

[headius]

I have fixed the Windows hangs by bypassing the launcher altogether. We have no explanation for it hanging, as both the tarball and a local HEAD build on Windows 10 both work fine, with either a good or bad JDK.

Bypassing the launcher for this JRuby-specific logic is also probably better; it's fewer processes to launch and avoids variability in the launcher behavior.

[headius]

All tests are green with none hanging at 31ccf06.

[eregon]

OK, quite weird, but this solution seems alright, merging.

[headius]

Is the fix released then? I just started a new jruby-dev-builder release but cancelled it when I saw you merged.

[eregon]

Yes, it's released, the passing CI green here means everything is fine.

[eregon]

This should be $JAVA_HOME/bin/java (or process.env, you get the idea) as java in PATH might resolve to something different and in fact it does I saw /usr/bin/java in logs. Could you make a PR to address that?

[eregon]

#723