chore(ios): bump build number to 183 [skip-ci] - #461
Merged
Conversation
Local ships failed at archive with four signing errors — no App Groups capability, no group support, missing entitlement, and "Xcode managed but signing settings require a manually managed profile". All four came from one wrong value: provision_profile_uuid named an Xcode-managed profile carrying no App Groups entitlement, while the correct manual profile sat unused. Profiles now come from dedicated 1Password items that hold the .mobileprovision as an attachment, and the UUID is derived from that file rather than read from a separate field, so it cannot drift from the profile it names. Configure with OP_PROFILE_VAULT, OP_APP_PROFILE_ITEM and OP_WIDGET_PROFILE_ITEM; without them the previous UUID-field and Xcode-cache path still applies. bootstrap-ios-signing.sh now installs profiles from base64 outside the cert-import block. That block only runs when a Distribution cert is supplied, which is the CI path, so local runs never installed profiles from base64 at all and a cache miss surfaced only as an archive failure. Decoded profiles are validated as real .mobileprovision files so a truncated secret fails at bootstrap instead of mid-archive. Adds --dry-run, which reports every field and both profiles without writing .p8, .env.signing or installing anything. It names the specific missing field instead of letting op fail inside a command substitution, which is what identified the gap here.
…igning env sentry-cli runs as a build phase during archive and aborts the build when it has credentials for neither org nor project. CI supplies SENTRY_AUTH_TOKEN, SENTRY_ORG and SENTRY_PROJECT from repository secrets, but a local ship had no source for them, so the archive died mid-build and the only way through was SENTRY_DISABLE_AUTO_UPLOAD=true — which silently costs symbolication. bootstrap-local-signing-op.sh now reads all three from a 1Password item and bootstrap-ios-signing.sh appends them to .env.signing, which ship-ios.sh already sources. Writing them from the generator rather than by hand is deliberate: .env.signing is regenerated wholesale on every bootstrap, so hand-added values disappear on the next run. SENTRY_ORG defaults to the org_slug field. sentry-cli builds API paths from the slug, so an org id 404s, and a login username — the first guess here — resolves to nothing at all. Sentry stays optional throughout: absent config warns but never blocks signing, since CI supplies its own and a missing Sentry item should not stop a ship. Also chmod 600 on .env.signing, which now carries an auth token rather than only paths and UUIDs.
services/sentry.ts reads the DSN from EXPO_PUBLIC_SENTRY_DSN and skips Sentry.init entirely when it is empty, and EXPO_PUBLIC_* values are inlined by Metro at bundle time. The variable was set nowhere the build could see it: not in deploy.yml, not a repository secret, and .env is gitignored so a CI checkout has no file to read it from. Every build produced by this workflow therefore shipped with Sentry uninitialised and reported no crashes at all. The three SENTRY_* entries already present are build-time only — they authorise sentry-cli to upload dSYMs, which is symbolication for events that were never sent. Wired into both jobs since they bundle the same JS. Sourced from vars rather than secrets because the DSN is inlined into the shipped app and is public by design (services/sentry.ts:38); masking it in logs would hide nothing while making "was it set?" harder to diagnose, which is what made this hard to spot.
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.
Automated version bump after successful ios upload.