[match] Fix match nuke deletion for provisioning profiles with wildcard filenames#30014
Conversation
iBotPeaches
left a comment
There was a problem hiding this comment.
Looks good. I confirmed --literal-pathspecs was added to git in 2011, so plenty old enough to assume everyone has it.
There was a problem hiding this comment.
Hey @nakshatrasinghh 👋
Thank you for your contribution to fastlane and congrats on getting this pull request merged 🎉
The code change now lives in the master branch, however it wasn't released to RubyGems yet.
We usually ship about once a month, and your PR will be included in the next one.
Please let us know if this change requires an immediate release by adding a comment here 👍
We'll notify you once we shipped a new release with your changes 🚀"
There was a problem hiding this comment.
Congratulations! 🎉 This was released as part of fastlane 2.234.0 🚀
Checklist
bundle exec rspecfrom the root directory to see all new and existing tests passbundle exec rubocop -ato ensure the code style is validci/circlecibuilds in the "All checks have passed" section of my PR (connect CircleCI to GitHub if not)Motivation and Context
Resolves #30002
match nukecan fail when deleting provisioning profiles from git-backed storage if a profile filename contains a literal wildcard character, such as*.Although fastlane shell-escapes the filename before calling
git rm, Git still interprets the argument as a pathspec. This can cause a wildcard profile filename to match neighboring profile files, so a later deletion command fails withpathspec ... did not match any files.Description
This updates
Match::Storage::GitStorage#delete_filesto remove files with:Using Git's literal pathspec mode makes wildcard characters in provisioning profile filenames behave literally while preserving the existing shell escaping.
A regression spec was added for git-backed storage deletion with both a literal wildcard provisioning profile filename and a neighboring filename that would previously be matched by that wildcard.
Testing Steps
Targeted tests:
Result:
Style check:
Result:
I also validated the behavior with a temporary local bare git remote containing wildcard and neighboring provisioning profile filenames. The patched deletion flow removed all files successfully, while reproducing the old
git rm <escaped path>behavior failed on the second matched profile, matching the reported issue.