Fix red master: keep the tests' Bundler runs out of OCRAN's own lockfile - #55
Merged
Conversation
`bundle exec` exports BUNDLE_LOCKFILE with the absolute path of the lockfile it used, and the suite itself runs under `bundle exec rake test`, so every child it spawns inherits OCRAN's own Gemfile.lock by name. Bundler believes that variable over the Gemfile it is handed: bundle_exec_env, resolving a fixture Gemfile to find out what `bundle exec` sets, wrote the fixture's dependencies into OCRAN's lockfile instead of the fixture's own. Nothing in the test run noticed. What noticed was the next step in the same CI job that ran `bundle exec` - on Windows, the zlib portability build - which died in frozen mode over a lockfile that had `mylocal` in it and none of OCRAN's development gems. Linux and macOS run that step under plain `ruby` and so stayed green while carrying the same damaged lockfile. Clearing BUNDLE_LOCKFILE puts the lockfile back where Bundler would put it on its own, next to the Gemfile - for a fixture, the temporary directory it was copied into, which is removed with the rest of it. The lockfile is compared against its pre-run content after every such Bundler run, so the next variant of this names itself. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
A test that lets Bundler write into the working tree leaves the suite green and breaks a later step with an error that names neither the test nor the fact that a test was responsible - the Windows jobs reported a frozen-mode Bundler failure in a build step minutes after the run that caused it. Checking the tree right after the tests puts the failure where the cause is. Tracked files only: bundle install populates vendor/bundle, and the builds leave stubs and packed executables behind. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
`branches: ['*']` does not match `fix/...` or `feat/...`: a single star stops at a slash. Every branch this project uses was therefore merged untested, and master was the first place the tests ever ran on it - the last two merges both turned it red. workflow_dispatch as well, so a run can be asked for without a push. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
vendor/ and .bundle/config are under version control here, and CI writes to both before a test runs: ruby/setup-ruby sets `deployment: true` in the config, and `bundle install` rewrites the vendored gems, whose shebangs and line endings differ per platform. On Windows that is some four thousand modified files, none of them anything a test did. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
masteris red on Windows only, in the step Build zlib fixture for portability test:Root cause
bundle execexportsBUNDLE_LOCKFILEholding the absolute path of the lockfile it used. The test suite runs underbundle exec rake test, so every child process it spawns inheritsBUNDLE_LOCKFILE=<repo>/Gemfile.lock.bundle_exec_env(added in #54) runsbundle exec ruby -e ...withBUNDLE_GEMFILEpointed at a fixture Gemfile — fortest_bundle_exec_own_bundle_is_not_warned_about,test/fixtures/localgem/Gemfile, copied to a tmpdir. Bundler believesBUNDLE_LOCKFILEover the Gemfile it was handed, so it resolved the fixture and wrote the result —PATH remote: mylocaland nothing else — into OCRAN's ownGemfile.lock, not the fixture's.Every platform did this. Only Windows noticed: its post-test zlib step runs
bundle exec ruby ..., andruby/setup-rubyhas putdeployment: truein.bundle/config, so Bundler refuses the rewritten lockfile. Linux and macOS run that step under plainrubyand stayed green while carrying the same damage.(The repo-local
deployment: truenever applied to the offending call itself: withBUNDLE_GEMFILEin a tmpdir,.bundle/configis out of Bundler's root, so nothing stopped the write.)Fix
bundle_exec_envclearsBUNDLE_LOCKFILE, which puts the lockfile back where Bundler would put it unaided — next to the Gemfile, i.e. inside the temporary copy that is deleted with the rest of the fixture. The tests still run real Bundler against real fixture Gemfiles; nothing is weakened.vendor/and.bundle/excluded — both are checked in but rewritten bybundle installandsetup-rubybefore any test runs).branches: ['*']never matchedfix/...orfeat/...: a single star stops at a slash. Every branch here was merged untested, which is how the last two merges reached master red. Now'**', plusworkflow_dispatch.Verification
Windows on this branch, run https://github.com/Largo/ocran/actions/runs/31359567122 —
run-tests-windows3.3 / 3.4 / 4.0 and all threetest-windows-portabilityjobs green. Linux and macOS jobs were still waiting for runners at the time of writing; locally,bundle exec rake testleaves the tree clean and shows only this box's known failures.🤖 Generated with Claude Code