eas-cli
eas-cli copied to clipboard
EAS internal distribution build invalidates provisioning profiles
Build/Submit details page URL
No response
Summary
We have two provisioning profiles set up, one for the app store and one for ad hoc. Currently, normal eas builds get signed and pass just fine, but when we do an internal distribution build interactively with eas build --profile internal --platform ios with the profile:
"internal": {
"channel": "internal",
"developmentClient": true,
"distribution": "internal"
},
In the Fetch Apple provisioning profiles step, it invalidates both profiles from our Apple account, and therefore any subsequent build will fail, internal or app store, forcing us to resave our profiles in our Apple account and re-upload them to Expo.
Managed or bare?
Managed
Environment
System:
OS: macOS 12.5.1
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 16.17.0 - ~/.nvm/versions/node/v16.17.0/bin/node
npm: 8.15.0 - ~/.nvm/versions/node/v16.17.0/bin/npm
SDKs:
iOS SDK:
Platforms: DriverKit 21.4, iOS 15.5, macOS 12.3, tvOS 15.4, watchOS 8.5
IDEs:
Xcode: 13.4.1/13F100 - /usr/bin/xcodebuild
npmPackages:
expo: ^45.0.0 => 45.0.8
react: 17.0.2 => 17.0.2
react-dom: 17.0.2 => 17.0.2
react-native: 0.68.2 => 0.68.2
react-native-web: 0.17.7 => 0.17.7
npmGlobalPackages:
eas-cli: 2.3.0
Expo Workflow: managed
Error output
Provisioning profile (id: null) is no longer valid
Reproducible demo or steps to reproduce from a blank project
N/A
any update?
it's still happening @dsokal this does not play well for those of us who would like to manage the certs and profiles ourselves (through match).
Any update on this issue? This is really annoying, as even using eas build with the --local flag ends up invalidating one of the distribution profiles.
Any updates on this? We're seeing similar results, as we have apple sign in and any time a build gets pushed the sign in breaks, this is really annoying and is generating issues with the client. this is pressing enough that we are considering exiting eas all together unless it is fixed
If I'm not mistaken, this bug makes the "--non-interactive" flag useless for iOS since the provisioning profiles will always be invalid