eas-cli
eas-cli copied to clipboard
Building iOS app invalidates provisioning profile when using document picker
Build/Submit details page URL
No response
Summary
I've migrated to EAS build and in the same time I've used iCloud service with expo DocumentPicker.
So I'm no sur which is causing this issue...
But each time I launch a new build I'm facing Provisioning profile (id: *******979) is no longer valid
If I answer Yes to Generate a new Provisionning Profile
it generate a new one correctly and it works ... But if I run the command again (like 10 sc later) the previous (freshly generated) provisionning profil is now invalid ...
It may be linked to iCloud.
I've added "usesicloudstorage": true
in my app.json
I also have this configured in my app identifier :
With an container named iCloud.<your_bundle_identifier>
as mentionned in the documentPicker docs
$ eas --version
eas-cli/0.50.0 win32-x64 node-v16.13.1
Managed or bare?
Managed
Environment
npx expo-env-info
expo-env-info 1.0.2 environment info:
System:
OS: Windows 10 10.0.19041
Binaries:
Node: 16.13.1 - C:\Program Files\nodejs\node.EXE
npm: 8.1.2 - C:\Program Files\nodejs\npm.CMD
SDKs:
Android SDK:
API Levels: 30
Build Tools: 30.0.3
System Images: android-30 | Google APIs Intel x86 Atom
IDEs:
Android Studio: Version 4.2.0.0 AI-202.7660.26.42.7351085
npmPackages:
expo: ^43.0.0 => 43.0.5
react: 17.0.1 => 17.0.1
react-dom: 17.0.1 => 17.0.1
react-native: 0.64.3 => 0.64.3
react-native-web: 0.17.1 => 0.17.1
Expo Workflow: managed
Error output
No response
Reproducible demo or steps to reproduce from a blank project
I think it happens with any blank project
I've been having basically the exact same issue, but do not use iCloud in our app
This sth we are aware of, We don't have any plans to fix it in the near future, as far as I understand the only problem here is that profile is regenerated every time which is not a problem (you do not need to login to apple for every build)
Well as far as I know I DO have to login for each build I want to send to testflight :/
And btw the certificat page will be a huge mess in a while ...
Well as far as I know I DO have to login for each build I want to send to testflight :/
You don't need to login when building for appstore(for ad-hoc builds you do) if your have credentials already configured. For submitting you need to login only if you don't have ascAppId specified in eas.json.
This issue is stale because it has been open for 30 days with no activity. If there is no activity in the next 7 days, the issue will be closed.
This issue was closed because it has been inactive for 7 days since being marked as stale. Please open a new issue if you believe you are encountering a related problem.
Can we reopen this? This problem still happens to me with latest CLI versions.
@wkozyra95 Could you reopen this please? It's still an issue
Can you please reopen this issue. It does not appear to be solved yet.
👍 same issue here. Any news on that?
Thank you for filing this issue! This comment acknowledges we believe this may be a bug and there’s enough information to investigate it. However, we can’t promise any sort of timeline for resolution. We prioritize issues based on severity, breadth of impact, and alignment with our roadmap. If you’d like to help move it more quickly, you can continue to investigate it more deeply and/or you can open a pull request that fixes the cause.
thanks, we'll investigate. you can work around this with EXPO_NO_CAPABILITY_SYNC=1 eas build
for now, or re-generated the profile every build automatically. more info
This same thing started happening to us after following OneSignal's instructions for enabling Push Notifications when doing our next TestFlight build.
Note: I built for the simulator and for the dev-client without running into this issue and both builds correctly include the OneSignal packages - and the dev-client receives notifications from OneS correctly.
Now it's a bit unclear whether the workaround (EXPO_NOCAPABILITY_SYNC=1) should be used immediately or after the first capability sync. E.g. will I have our new push capability in a new build without doing the sync.
And if I get asked again, is Y or n the correct answer for the workaround?
Now it's a bit unclear whether the workaround (EXPO_NOCAPABILITY_SYNC=1) should be used immediately or after the first capability sync. E.g. will I have our new push capability in a new build without doing the sync.
No workaround is strictly necessary, the only problem with the current state is that it regenerates a new profile even if it's not necessary. You should set EXPO_NO_CAPABILITY_SYNC when you know that there is nothing new to sync, so you need to run without that env only when changing entitlements in app.json or if are changing/adding/removing config-plugin that might modify entitlements.
And if I get asked again, is Y or n the correct answer for the workaround?
Answering no to login to apple prompt will also stop syncing profile, but e.g. internal distribution build requires login to apple, so it will not work in every case.
Every time I run EXPO_DEBUG=true eas build --platform ios --profile profilename
it figures out (incorrectly) that Provisioning profile (id: 6BJB75X655) is no longer valid
, however it was created just seconds earlier using the same command and is listed as valid in the expo GUI until next year. This breaks our CI builds. I guess we'll have to resort to EXPO_NOCAPABILITY_SYNC=1
for now
Will this work properly if we update expo-document-picker
?
This issue is stale because it has been open for 30 days with no activity. If there is no activity in the next 7 days, the issue will be closed.
Still an issue, not stale
I'm not using expo-document-picker
but i am using with-rn-image-crop-picker
.
Same issue here every single time.
This issue is stale because it has been open for 30 days with no activity. If there is no activity in the next 7 days, the issue will be closed.
Issue is still here
This issue is stale because it has been open for 30 days with no activity. If there is no activity in the next 7 days, the issue will be closed.
This is definitely an issue. Every time I have to change/select a certificate using the eas-cli
, Certificates on Apple Developers get disabled.
Are we getting a fix? :)
This issue is stale because it has been open for 30 days with no activity. If there is no activity in the next 7 days, the issue will be closed.
Still a problem, not stale
This issue is stale because it has been open for 30 days with no activity. If there is no activity in the next 7 days, the issue will be closed.
still not stale :|
Same problem as @pkreipke once adding OneSignal to the mix, now every build incorrectly says provisioning file is invalid and generates a new one, next build the exact same thing. We need a fix as it is very annoying and adding the env var is likely to cause issues for some when changing entitlements as https://github.com/expo/eas-cli/issues/1069#issuecomment-1277391690 mentions and not knowing/remembering this is the "fix"