Skip macOS resource fork files in upgrade migration parser#31012
Skip macOS resource fork files in upgrade migration parser#31012ellabaron-code wants to merge 3 commits intoyugabyte:masterfrom
Conversation
macOS embeds ._ resource fork files inside release tarballs. When extracted, these mirror the original .sql filenames and pass the extension check but fail the migration name regex, causing test failures on macOS.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a check to skip macOS resource fork files (starting with '._') during YSQL migration compatibility validation to prevent processing errors. The reviewer suggests making this check unconditional by removing the platform-specific guard, as these metadata files can appear on other operating systems if a tarball created on macOS is extracted there.
✅ Deploy Preview for infallible-bardeen-164bc9 ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
trigger Jenkins |
|
Phorge diff synced: D52008 Jenkins build has been triggered. Results will be posted here once it completes. JenkinsBot |
|
✅ Jenkins build for commit Passed: 12 🔨 DB Build/Test Job Summary
JenkinsBot |
|
trigger jenkins |
|
Phorge diff synced: D52008 Jenkins build has been triggered. Results will be posted here once it completes. JenkinsBot |
|
@ellabaron-code please update the PR description with what the fix is. |
|
Hi Hari, |
4 participants
Summary
Skip macOS AppleDouble resource-fork files (
._*) during upgrade-test tarball extraction so they never reachValidateYsqlMigrationCompatibility.Problem
Upgrade integration test,
xcluster_upgrade-itest, fails on macOS when loading an old-version release tarball.The release tarballs are built on macOS, which embeds
AppleDoublecompanion files (._V53__22144__foo.sqlnext to eachV53__22144__foo.sql) to preserve HFS+ extended attributes. Whengtarextracts the tarball on another macOS host, those companions are faithfully written to disk alongside the real migrations.ValidateYsqlMigrationCompatibilitywalksshare/ysql_migrations/, filters.sqlby suffix (which._V…sqlpasses), and then fails the filename-regex check with:Invalid migration file name:
._V53__22144__foo.sqlFix
Pass
--exclude=._*to the tarxzfinvocation inDownloadAndGetBinPath. The junk never lands on disk, so no downstream code needs to know it existed.Works with both
taron Linux andgtaron macOS (both GNU tar); the flag is a no-op on tarballs that don't contain._*entries.Why this approach
Earlier iterations filtered the files inside the migration reader. That's more fragile — any future code that walks the extracted tree (not just the migration validator) would hit the same problem and have to re-discover the fix. Excluding at extraction time fixes it once, at the source.
Test plan
xcluster_upgrade-iteston macOS — this is the reliable verifier: without the fix it fails atValidateYsqlMigrationCompatibilityon._*migration files, and with the fix it passes end-to-end.cluster_upgrade-iteston Linux to confirm the extra--exclude=._*flag doesn't regress anything.Phorge: D52008