test(docker): gate the MPRv2 Build guard on Mendix >= 11.6.1 (fixes the 10.24 nightly) - #73
Merged
Merged
Conversation
The nightly matrix runs integration tests against 10.24.19.104498, 11.6.6 and 11.12.0. TestBuild_PreservesMPRv2StorageFormat, added with the mendixlabs#808 fix, failed on the 10.24 row only: Build failed: portable app distribution requires Mendix >= 11.6.1, found 10.24.19.104498 10.24 is MPRv2 (v2 storage arrived in 10.18), so the test's storage-format precondition passed and it went on to call Build, which refuses below 11.6.1 before it ever reaches the update-widgets step the test is about. The failure is a property of the matrix row, not a regression in the fix. The 11.x rows are unaffected, which is why only one job went red. Adds the missing precondition. This is a real capability gate rather than a masked failure: there is no portable app distribution to protect on 10.x, and TestCheck_PreservesMPRv2StorageFormat has no version guard, so MPRv2 preservation is still covered on every matrix row — it passes on 10.24 today. Reproduced and verified against real MxBuild installs rather than reasoned about: only 10.24 cached, before -> FAIL (the exact CI error) only 10.24 cached, after -> SKIP, and Check still PASSes only 11.x cached, after -> PASS (39s — the test still genuinely runs) The last of those matters most: a version gate that silently disabled the test everywhere would be worse than the failure it fixes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012XR649rKk68z6gBpngu6MA
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
2 participants
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.
Fixes the nightly failure on the Mendix 10.24.19.104498 matrix row (run 30685895419). My regression, introduced with the mendixlabs#808 fix.
What happened
The nightly matrix is
['10.24.19.104498', '11.6.6', '11.12.0'].TestBuild_PreservesMPRv2StorageFormatfailed on the 10.24 row only:10.24 is MPRv2 — v2 storage arrived in 10.18 — so the test's storage-format precondition passed, and it went on to call
Build, which refuses below 11.6.1 before ever reaching theupdate-widgetsstep the test is about. The failure is a property of the matrix row, not a regression in the mendixlabs#808 fix itself. Both 11.x rows clear the guard, which is why exactly one job went red.The fix
Adds the missing precondition. This is a genuine capability gate, not a masked failure — there is no portable app distribution to protect on 10.x. And coverage is not lost:
TestCheck_PreservesMPRv2StorageFormathas no version guard, runs on every matrix row, and passes on 10.24 today, so MPRv2 preservation is still verified there.Verified against real MxBuild installs, not reasoned about
FAIL— the exact CI errorSKIP, andCheckstillPASSPASS(39s — the test still genuinely runs)The last row is the one that matters. A version gate that silently disabled the test on every row would be worse than the failure it fixes — and that exact trap (a skip reading as a pass) is what let mendixlabs#808's original test sit dormant in the first place.
I reproduced the failure by downloading MxBuild 10.24.19.104498 and hiding the 11.x caches so resolution matched the CI job, rather than inferring from the version guard.
Follow-up worth considering
The nightly's integration step gives no signal about skips. If a future test skips on every row for an unintended reason, the job stays green. Adding
-vand surfacing the skip count would make that visible — happy to do it if you want, but it's a separate change from unbreaking the build.🤖 Generated with Claude Code
https://claude.ai/code/session_012XR649rKk68z6gBpngu6MA
Generated by Claude Code