Issue running danger-junit on M1 CI machines

[Panajev]

Hello @orta due to a dependency to the Ox gem, it appears the junit report functionality is broken on M1 machines, have you run into this issue? Do you have any advice or could you offer any help to work around this problem with danger-junit?

Raised it with the Ox project too in order to see if a fix could be developed there (bit sad as we do not quite know what it entails at the moment so not able to commit a PR to fix this issue at the source sadly): ohler55/ox#297

/CI/Jenkins/workspace/tests-NA-all-commits-ios-Lobby-pr/ruby_path/ruby/3.1.0/gems/ox-2.14.11/lib/ox.rb:79:in `require': dlopen(/CI/Jenkins/workspace/tests-NA-all-commits-ios-Lobby-pr/ruby_path/ruby/3.1.0/gems/ox-2.14.11/ext/ox/ox.bundle, 0x0009): tried: '/CI/Jenkins/workspace/tests-NA-all-commits-ios-Lobby-pr/ruby_path/ruby/3.1.0/gems/ox-2.14.11/ext/ox/ox.bundle' (mach-o file, but is an incompatible architecture (have (x86_64), need (arm64e))) - 

We researched the issue and tried the commonly suggested workarounds like:

Ensuring all gems would be installed with the native extensions recompiled for the host machine:

bundle config set --local force_ruby_platform true

and/or

bundle config set force_ruby_platform true

We do have ruby as one of the supported platforms in our Gemfile.lock btw:

PLATFORMS
  arm64-darwin-21
  ruby
  x86_64-darwin-19
  x86_64-darwin-20
  x86_64-darwin-21

Adding the following platform restriction in the Gemfile:

# HACK(bouk): Overwrite Bundler's platform matcher to ignore universal CPU
# The protobuf and gRPC 'universal' macOS gems break on M1
module Bundler::MatchPlatform
    def match_platform(p)
      return false if ::Gem::Platform === platform && platform.cpu == "universal"
      Bundler::MatchPlatform.platforms_match?(platform, p)
    end
end

But nothing seems to do the trick :/...

---

References: protocolbuffers/protobuf#8199 (and similar ones)

[Panajev]

Hello @orta, it seems like it was a stupid issue although curious too. We were using AdoptOpenJDK's JDK11 on the M1 based agents and this was resulting in the local setup being done in native aarch64 mode while the Jenkins CI agent jar was launched from an x86_64 context resulting in the hilarity above.

There are some other issues on Monterey 12.6 + Xcode 14, but they do not seem to affect this scenario in particular.

Solution: for us it was as simple as migrating to Temerin's JDK11 which has a native Apple Silicon version.