fix(#585): validate carried kernel patches against the patched kernel in CI - #586
Merged
Merged
Conversation
… in CI ci.yml's macOS check always resolves Package.swift's pinned, released OCCT.xcframework, since a clean checkout has no local Libraries/. A PR carrying a kernel patch not yet in a release, with a regression test for its fixed behaviour, fails that check indistinguishably from a real regression - #519 hit this exactly and needed a manual dig to tell the two apart. New kernel-integration.yml, path-filtered to Scripts/patches/** and Scripts/build-occt.sh so ordinary PRs stay on the fast ci.yml path: rebuilds OCCT from source (cached by patch-set hash, so only the first run after a patch change pays the ~30-60 min cost) and runs swift test against that binary instead of the pinned release. Fulfils what the old ci.yml comment already named and never built: a "kernel-rebuild.yml" that never existed anywhere in this repo's history. Closes #585. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
gsdali
added a commit
that referenced
this pull request
Jul 31, 2026
…ness Merging with the macOS CI check red, same known kernel-pin gap as #519/#576/#586 — refactor/381-pass1b's tip permanently carries #519's regression tests until a release bumps Package.swift's pin. Confirmed via local run against the actual patched kernel: exactly the same 23-issue Issue522/Issue491 signature, nothing new from this PR (which is comment/docs-only in OCCTBridge.h + a tooling script). Two conflicts resolved during merge, both stale-branch artifacts (this PR's branch predates #507/#508's already-merged fixes to the same two OCCTBridge.h index entries) — kept the already-more-complete HEAD content in both spots, verified via `check-bridge-index.py` (0 stale, 5/5 self-test) after resolution. Third conflict in check-bridge-index.py itself: kept #510's continuation-line-aware parser (a strict superset of the current parenthetical-stripping one, already implied by the file's own already-merged docstring).
gsdali
added a commit
that referenced
this pull request
Jul 31, 2026
Merging with the macOS CI check red, same known kernel-pin gap as #519/#564/#576/#586. Confirmed locally against the actual patched kernel: exactly the same 23-issue Issue522/Issue491 signature, nothing new. Clean cherry-pick, zero conflicts. Verified with the PR's own new check-null-handle-guards.py: "All bridge functions guard the geometry handle as well as the wrapper pointer."
gsdali
added a commit
that referenced
this pull request
Jul 31, 2026
…adius Merging with the macOS CI check red, same known kernel-pin gap as #519/#564/#574/#576/#586. Resolved the predicted trivial conflict with #574 in OCCTGeom2dGccCirc2dTanOnRad: both PRs insert an independent guard as the function's first statement (null-handle from #574, zero-radius from #575), kept both. Verified post-merge: all 22 of this PR's own tests pass (including the merged function's own case), and check-null-handle-guards.py still reports clean (#574's fix intact).
gsdali
added a commit
that referenced
this pull request
Jul 31, 2026
kernel-integration.yml (added an hour ago, #586) fails on every cache miss before it reaches the patch it exists to validate: ./Scripts/build-occt.sh: line 71: cd: .../Libraries: No such file or directory Libraries/ is gitignored in its entirety, so a clean checkout does not have it, and actions/cache does not create the path on a miss. Since a cache miss is exactly what a new or changed patch produces, the workflow could not have passed for any kernel-patch PR. #532 is the first PR to trigger it. Reproduced on a scratch layout matching a clean checkout: stock script dies on line 71 with the same message, patched script creates the directory, clones OCCT, configures and starts compiling. The mkdir goes in build-occt.sh rather than the workflow, because the script's own first-run contract is the same for anyone building locally from a fresh clone. Second defect, silent rather than fatal: the job restores ~/Library/Caches/org.swift.swiftpm, which caches the manifest *evaluation*, including the `useLocalBinary` filesystem probe that ran before Libraries/OCCT.xcframework existed. A restored cache makes SwiftPM keep resolving the pinned released kernel, so the job would validate the wrong binary and report green -- the failure mode this workflow was built to prevent, wearing a passing tick. Measured on #532: touching Package.swift, deleting .build/artifacts/*/OCCT, `swift package resolve` and a full `swift package reset` all failed to dislodge it. `OCCTSWIFT_LOCAL=1` -- the override Package.swift already documents -- is what works, so the test step now sets it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
gsdali
added a commit
that referenced
this pull request
Jul 31, 2026
kernel-integration.yml (added an hour ago, #586) fails on every cache miss before it reaches the patch it exists to validate: ./Scripts/build-occt.sh: line 71: cd: .../Libraries: No such file or directory Libraries/ is gitignored in its entirety, so a clean checkout does not have it, and actions/cache does not create the path on a miss. Since a cache miss is exactly what a new or changed patch produces, the workflow could not have passed for any kernel-patch PR. #532 is the first PR to trigger it. Reproduced on a scratch layout matching a clean checkout: stock script dies on line 71 with the same message, patched script creates the directory, clones OCCT, configures and starts compiling. The mkdir goes in build-occt.sh rather than the workflow, because the script's own first-run contract is the same for anyone building locally from a fresh clone. Second defect, silent rather than fatal: the job restores ~/Library/Caches/org.swift.swiftpm, which caches the manifest *evaluation*, including the `useLocalBinary` filesystem probe that ran before Libraries/OCCT.xcframework existed. A restored cache makes SwiftPM keep resolving the pinned released kernel, so the job would validate the wrong binary and report green -- the failure mode this workflow was built to prevent, wearing a passing tick. Measured on #532: touching Package.swift, deleting .build/artifacts/*/OCCT, `swift package resolve` and a full `swift package reset` all failed to dislodge it. `OCCTSWIFT_LOCAL=1` -- the override Package.swift already documents -- is what works, so the test step now sets it. Co-Authored-By: Claude Opus 5 (1M context) <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
1 participant
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.
Summary
ci.yml's macOS check always resolvesPackage.swift's pinned, releasedOCCT.xcframework— a PR carrying a kernel patch not yet in a release, with a regression test for its fixed behaviour, fails that check indistinguishably from a real regression. chore(#512) + fix(#518, #555, #522): rebuild the kernel, redesign 0016 after upstream review, add 0018 and 0019 #519 hit this exactly and needed a manual investigation to tell "expected structural gap" apart from "the patch is broken."kernel-integration.yml, path-filtered toScripts/patches/**andScripts/build-occt.sh(ordinary PRs stay on the fastci.ymlpath): rebuilds OCCT from source, cached by patch-set hash so only the first run after a patch change pays the full ~30-60 min cost, then runsswift testagainst that binary instead of the pinned release.ci.ymlcomment already named and never built — akernel-rebuild.ymlthat never existed anywhere in this repo's history.ci.yml's comment updated to point at the new workflow instead of describing the rebuild as manual-only;docs/guides/building-occt.mdupdated in both places it discussed CI/kernel-rebuild interaction.Closes #585.
Test plan
yaml.safe_load).Scripts/count-operations.pyunaffected (no Swift API change).kernel-integration.ymlon this PR itself (it touchesScripts/build-occt.sh's neighbourhood only via docs, not the script — will confirm the path filter and cache key behave correctly on the next PR that actually touchesScripts/patches/).