fix(tests): pass the absolute path to the executable classifier - #345
Conversation
📝 WalkthroughSummary by CodeRabbit
WalkthroughNative manifest construction now passes each file’s full path to ChangesNative manifest launch
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
Suggested labels: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Files Reviewed (1 file)
Reviewed by glm-5.2 · Input: 16.4K · Output: 2.7K · Cached: 174.7K |
developmentdoes not compile: #332 and #339 merged without a textual conflict, but #339 changedExecutableFileClassifier.RequiresExecutePermissionto require anabsolutePathargument, leaving one stale call site in the tests #332 added.All three CI jobs fail at Run Tests with:
The loop already has the absolute path in hand, so it is passed through rather than switching to
RequiresExecutePermissionFromName. That gives the magic-byte check #339 introduced, matching whatManifestGenerationServiceandContentManifestBuilderdo in production. This was the only remaining stale call site.Greptile Summary
The PR repairs the native-client manifest launch tests after the executable classifier began requiring an absolute path.
ExecutableFileClassifier.RequiresExecutePermission.Confidence Score: 5/5
The PR appears safe to merge, with the stale test call corrected to match the classifier’s current contract.
The enumerated file path is passed in the expected absolute-path parameter position, restoring compilation and enabling the intended magic-byte classification for extensionless native binaries.
Important Files Changed
Reviews (1): Last reviewed commit: "fix(tests): pass the absolute path to th..." | Re-trigger Greptile