Update usymtool file matching pattern in deployment script

[devcube9]

Changes

Fixes error /build/iOS/iOS/usymtoolarm64: Permission denied

Checklist

• Read the contribution guide and accept the
  code of conduct
• Readme (updated or not needed)
• Tests (added, updated or not needed)

Summary by CodeRabbit

• Documentation
  • Updated iOS deployment guide to broaden executable matching for the symbolication tool, accommodating name variants and improving setup reliability.

[github-actions]

[coderabbitai]

Walkthrough

Updated iOS deployment docs to change the executable-matching pattern from exact filename usymtool to wildcard usymtool*. No other content or logic is modified.

Changes

Cohort / File(s)	Summary
Docs: iOS deployment docs/03-github/06-deployment/ios.mdx	Revised command/pattern to make files starting with usymtool executable (from usymtool to usymtool*). No other edits.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Poem

I tap my paw, asterisk gleams,
From single tool to starry streams—
“usymtool*,” I softly cheer,
Matching friends both far and near.
Docs now hop with broader scope,
A wildcard wink, a bunny’s hope. 🐇✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description Check	⚠️ Warning	Although the required template headings are present, the Changes section does not use the expected bullet list format and only states the observed error without detailing the update to the file matching pattern; this makes the description incomplete and lacking context on what was changed and why.	Please update the Changes section to use bullet points that describe the specific modification (changing the filename pattern from “usymtool” to “usymtool*”) and explain how this fixes the permission issue, so that the description fully matches the template’s structure and provides clear context.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The title accurately and concisely summarizes the main change by indicating that the usymtool file matching pattern is updated in the deployment script.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 78682fd and 366fdfc.

📒 Files selected for processing (1)

• docs/03-github/06-deployment/ios.mdx (1 hunks)

🔇 Additional comments (1)

docs/03-github/06-deployment/ios.mdx (1)

488-488: Wildcard usymtool* fixes the permission miss

Allowing find to match usymtoolarm64 (and any future suffix variants) resolves the permission denied error without broadening the scope beyond the intended binaries. Thanks for tightening this up.

Tip

👮 Agentic pre-merge checks are now available in preview!

Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.

• Built-in checks – Quickly apply ready-made checks to enforce title conventions, require pull request descriptions that follow templates, validate linked issues for compliance, and more.
• Custom agentic checks – Define your own rules using CodeRabbit’s advanced agentic capabilities to enforce organization-specific policies and workflows. For example, you can instruct CodeRabbit’s agent to verify that API documentation is updated whenever API schema files are modified in a PR. Note: Upto 5 custom checks are currently allowed during the preview period. Pricing for this feature will be announced in a few weeks.

Please see the documentation for more information.

Example:

reviews:
  pre_merge_checks:
    custom_checks:
      - name: "Undocumented Breaking Changes"
        mode: "warning"
        instructions: |
          Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).

Please share your feedback with us on this Discord post.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}