Call "add-platform" before "bundle install" when using cache

[starburst997]

I've ran into an annoying issue using macos runner on Github Action and using lockfile where the platform id could change at a moment notice meaning that I would be greeted with this error:

Your bundle only supports platforms ["x64-mingw-ucrt", "x86_64-linux", "x86_64-darwin-21"] but your
local platform is x86_64-darwin-22. Add the current platform to the lockfile
with
`bundle lock --add-platform x86_64-darwin-22` and try again.

Obviously, running bundle lock --add-platform x86_64-darwin-22 fixes the issue, but that action used to run without any issues and now despite using macos-13 (not macos-latest), I get this error. Very annoying and not "future-proof".

So I propose the addition of the add-platform input which call this command before bundle install ensuring that the platform is present in the lockfile.

[eregon]

This is a case where the Gemfile.lock is committed in git right?
I think this would fail the check that the Gemfile.lock is not modified (from the deployment flag).

The 22 in x86_64-darwin-22 is AFAIK the darwin kernel version, that should only change with a different macOS version.

[starburst997]

Correct, the Gemfile.lock is committed in git.

I was surprised by it (and maybe this is a bug on github side), but I am pretty sure that the macos-13 runners used to be x86_64-darwin-21 and now I am getting x86_64-darwin-22. Regardless, let's say I was using macos-latest, this is an issue that would happens eventually, which is not really an issue on linux since the platform name is consistent (ubuntu-latest being x86_64-linux).

[eregon]

I was surprised by it (and maybe this is a bug on github side), but I am pretty sure that the macos-13 runners used to be x86_64-darwin-21 and now I am getting x86_64-darwin-22.

According to https://en.wikipedia.org/wiki/MacOS_Ventura#Release_history macOS 13 has always been darwin 22.

But what ruby -v shows and what RUBY_PLATFORM returns is not the the runtime version of the darwin kernel, it is the (CRuby) compile-time version of it!
So we have:
https://github.com/ruby/setup-ruby/actions/runs/13049552263/job/36406659966#step:4:7
ruby 3.2.6 (2024-10-30 revision 63aeb018eb) [x86_64-darwin21]
https://github.com/ruby/setup-ruby/actions/runs/13167306524/job/36750485255#step:4:7
ruby 3.2.7 (2025-02-04 revision 02ec315244) [x86_64-darwin22]

Both are run on the macos-13 runner, but the former was compiled on macos-12 (which is no longer available and so that's why we build on macos-13 now).

I think this is essentially a bug in CRuby and/or RubyGems/Bundler:

• In CRuby, RUBY_PLATFORM should maybe be the runtime platform and not the compile time one. I'm not sure why the version is even part of RUBY_PLATFORM on macOS, when it's not on other platforms. JRuby just uses x86_64-darwin, and TruffleRuby used to do that too but added the compile-time version for compatibility.
• RubyGems/Bundler should maybe ignore the kernel version and just consider them to be x86_64-darwin. That would solve it nicely, but maybe there are issues with that?
• RubyGems/Bundler could also actually get the runtime kernel version if that's necessary, it certainly seems more appropriate than the compile-time version.

Especially if gems with extensions are installed later, I think it makes little sense for RubyGems/Bundler to use the compile-time version.

Could you report the issue to Bundler?
I think this is a general problem, e.g. if multiple macOS users on a team have different versions then they need many bundle lock --add-platform x86_64-darwin-NN and this seems generally inconvenient and a usability issue.