### Summary When `GITLAB_BUNDLE_GEMFILE` points to a Gemfile outside the repository root, such as `jh/Gemfile`, Bundler local settings are written and read from different application roots. As a result, settings configured in `config/software/gitlab-rails.rb`, including: - `force_ruby_platform` - `build.io-event` - `build.ruby-magic` - Other current or future `build.*` settings can be reported as successfully configured but are not consumed by `bundle install`. This has been reproduced with Bundler 4.0.12 in a completely fresh builder container, without restoring a previous native extension or Omnibus build cache. ### Environment - Bundler: `4.0.12` - Ruby: `3.3.12` - Builder image revision: `5.65.0` - Custom Gemfile: `jh/Gemfile` - `io-event`: `1.16.2` - `ruby-magic`: `0.6.0` - Affected builders include: - AlmaLinux 9, glibc 2.34 - Amazon Linux 2023, glibc 2.34 - AlmaLinux 8 native gem builds can also be affected through `force_ruby_platform` ### Steps to reproduce Create a project with a root `Gemfile`: ```ruby source "https://rubygems.org" gem "io-event", "1.16.2" ``` Create `jh/Gemfile`: ```ruby eval_gemfile File.expand_path("../Gemfile", __dir__) ``` Run the same configuration order currently used by `gitlab-rails.rb`: ```shell bundle _4.0.12_ config set --local gemfile jh/Gemfile bundle _4.0.12_ config build.io-event --disable-epoll_pwait2 bundle _4.0.12_ install ``` The root configuration appears correct: ```yaml --- BUNDLE_GEMFILE: "jh/Gemfile" BUNDLE_BUILD__IO___EVENT: "--disable-epoll_pwait2" ``` Running this command from the repository root is misleading because it reports that the setting exists: ```shell bundle _4.0.12_ config get build.io-event ``` However, selecting the custom Gemfile before Bundler initializes shows that the setting is unavailable in the actual application context: ```shell BUNDLE_GEMFILE="$PWD/jh/Gemfile" \ bundle _4.0.12_ config get build.io-event ``` Output: ```text You have not configured a value for build.io-event ``` The native build log confirms that the option was not passed: ```text ruby extconf.rb ``` The resulting extension references the unsupported symbol: ```text epoll_pwait2@GLIBC_2.35 ``` The same behavior applies to: ```shell bundle config build.ruby-magic \ --with-magic-flags=--disable-zstdlib ``` The command succeeds, but `ruby-magic` is compiled without the option and the resulting `magic.so` links against the system `libzstd.so.1`. ### Current behavior `bundle config` writes the settings to: ```text gitlab-rails/.bundle/config ``` When `bundle install` selects `jh/Gemfile`, Bundler changes its application root and reads: ```text gitlab-rails/jh/.bundle/config ``` Therefore, the settings written to the root configuration are not visible during installation. This produces errors such as: ```text System GLIBC version: 2.34 Maximum required GLIBC version: 2.35 IO_Event.so epoll_pwait2@GLIBC_2.35 ``` Omnibus HealthCheck can also report: ```text magic.so libzstd.so.1 ``` ### Expected behavior When `GITLAB_BUNDLE_GEMFILE` specifies a custom Gemfile, all Bundler configuration and installation commands should operate in the same application context. The configured native extension options should be passed to the actual compilation commands: ```text ruby extconf.rb --disable-epoll_pwait2 ``` and: ```text ruby extconf.rb --with-magic-flags=--disable-zstdlib ``` The resulting binaries should: - Not reference `epoll_pwait2@GLIBC_2.35` - Not depend on the system `libzstd.so.1` ### Root cause The current implementation persists the custom Gemfile as a local Bundler setting: ```ruby bundle "config set --local gemfile #{gitlab_bundle_gemfile}" ``` This is also required by the installed-package runtime helper, which reads the root `.bundle/config` to locate the custom Gemfile. However, persisting the setting does not ensure that subsequent Bundler processes start in the custom Gemfile context. This issue does not normally affect upstream builds because they use the root `Gemfile`, so the configuration and installation roots remain the same. It primarily affects consumers of the supported `GITLAB_BUNDLE_GEMFILE` mechanism. The issue is related to [MR !6207](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/6207), which changed the configuration order after `force_ruby_platform` was found to be ineffective with `jh/Gemfile`. Moving the command earlier addressed the behavior at the time, but it does not fully resolve the application-root mismatch with Bundler 4. It is also related to the symptoms discussed in [MR !9563](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/9563). A `magic.so` HealthCheck exemption or individual `BUNDLE_BUILD__*` variables can hide or work around specific failures, but they do not address the shared configuration-scope problem. ### Proposed solution Keep the relative root configuration because it is needed by the installed-package runtime helper, but explicitly select the custom Gemfile for all subsequent Bundler commands: ```ruby if gitlab_bundle_gemfile != 'Gemfile' # Keep the root marker for runtime while building in the custom Gemfile context. bundle "config set --local gemfile #{gitlab_bundle_gemfile}" env['BUNDLE_GEMFILE'] = File.expand_path( gitlab_bundle_gemfile, File.join(Omnibus::Config.source_dir, 'gitlab-rails') ) end ``` The existing commands already receive `env`: ```ruby bundle 'config force_ruby_platform true', env: env bundle 'config build.io-event --disable-epoll_pwait2', env: env bundle 'config build.ruby-magic --with-magic-flags=--disable-zstdlib', env: env bundle 'install ...', env: env ``` This causes the application-local settings to be written to and read from the custom Gemfile directory consistently. ### Validation The proposed change was tested using the same AlmaLinux 9 builder image and Bundler 4.0.12. With a fresh first installation: ```text io-event: ruby extconf.rb --disable-epoll_pwait2 ``` The resulting `IO_Event.so` no longer references: ```text epoll_pwait2@GLIBC_2.35 ``` For `ruby-magic`: ```text ruby extconf.rb --with-magic-flags=--disable-zstdlib ``` The resulting `magic.so` no longer depends on: ```text libzstd.so.1 ``` `force_ruby_platform` is also correctly read from the custom application configuration. No per-gem `BUNDLE_BUILD__*` environment variables, HealthCheck exemptions, or `bundle pristine` commands are required for a fresh package build. The default upstream path remains unchanged because the new behavior is enabled only when: ```ruby gitlab_bundle_gemfile != "Gemfile" ``` A reference implementation is available in the JiHu fork: [JiHu omnibus-gitlab commit 9b9751a12](https://jihulab.com/gitlab-cn/omnibus-gitlab/-/commit/9b9751a123dfc30145a7b6ebe66be8559c9d66dd) ### Suggested labels - `type::bug` - `Category:Build` - `Category:Omnibus Package` - `JiHu contribution`