Virtual-environments: Default CLASSPATH with Selenium breaks JRuby

[headius]

It appears that the changes from https://github.com/actions/virtual-environments/pull/185 have caused Selenium's standalone server jar to be in the default system CLASSPATH environment variable. This needs to be removed.

https://github.com/jruby/jruby/issues/6023#issuecomment-572239586

That standalone jar contains a number of dependency libraries that have not been hidden or relocated ("shaded" in Maven parlance). As a result, any Java tools that have differing dependencies may pick up the wrong version of those libraries.

This is the cause of https://github.com/jruby/jruby/issues/6023 because the older SnakeYAML included in Selenium conflicts with the expected version for JRuby's YAML library.

I would expect all environments are affect, assuming they all set this default CLASSPATH.

The fix is to not set (NEVER set) a global default CLASSPATH.

[eregon]

https://github.com/actions/virtual-environments/blob/95954b3f022a1c4626d112bd4fe82d0812fa6f4b/images/linux/scripts/installers/google-chrome.sh#L74 seems the specific line setting CLASSPATH on Linux runners.

[headius]

Ok so perhaps only Linux environments are affected.

[eregon]

And https://github.com/actions/virtual-environments/pull/185/files#diff-5e79e2c7eccdc5e0edbd13c036ba94b6R32-R34 is probably what sets it on Windows.
macos-latest is not affected.

[headius]

cc @pkuczynski

[pkuczynski]

Clearing CLASSPATH solved issues in my build, but it does not sound like a sensible requirement to make the build successful, don't you think?

https://github.com/rubyconfig/config/pull/228/files#diff-353995fb5bebaef307ec25fa5be39042R18

[headius]

Another failing build: https://github.com/ruby/psych/pull/429/checks?check_run_id=380304944

This will affect all users running JRuby in Github Actions until it is resolved.

[eregon]

@bryanmacfarlane @alepauly Could you ping whoever at GitHub can fix this?
I think it breaks many GHA workflows and deserves a fairly urgent fix.

[alepauly]

@bryanmacfarlane @alepauly Could you ping whoever at GitHub can fix this?
I think it breaks many GHA workflows and deserves a fairly urgent fix.

thanks for the ping @eregon, I'm looking into it since the changes from #185 have not been deployed to production so it's possible something else is the problem.

edit: ok, the changes from #184 are included into what's going out to production and that's what broke it. I'm coordinating a fix now.

[pkuczynski]

For me the issue was intermittent. So maybe #185 was deployed to some workers? Clearing CLASSPATH solved it for all builds...

[alepauly]

For me the issue was intermittent. So maybe #185 was deployed to some workers? Clearing CLASSPATH solved it for all builds...

@pkuczynski the latest version which include #184 is not out in all machine pools so it is possible you've hit some of the older one versus the newer ones, correct. I stopped the roll out while we figure out what to do.

[alepauly]

@eregon @pkuczynski @headius building new images and validating takes a while so tomorrow morning (EST) we'll deploy a quick fix that applies the workaround automatically to all builds while we continue to validate the changes to rebuild the image to deploy as a final solution early next week. From your POV there will be no difference between the intermediate solution and the final one but just wanted to give some details on what we're working on. Thanks again for reporting!

[headius]

@alepauly Thank you for the quick turnaround!

[pkuczynski]

Thanks! I will wait for next week to test on my side.

[AndreyMaslennikov]

@headius, @pkuczynski, @eregon, I've created PR #247. It's already merged and should fix this issue.

[alepauly]

@headius, @pkuczynski, @eregon, I've created PR #247. It's already merged and should fix this issue.

Thanks @AndreyMaslennikov! One clarification though: the fix will deploy in the next build which should roll out next week. We are deploying the workaround today.

[headius]

We are deploying the workaround today.

Good enough for me!