Problem Statement - identical build runs result in different output (aps-environment entitlement is present in one build, but absent from another).
Long story short - integration with the OneSignal Expo plugin is failing with a “Missing Push Entitlement” error. After ~60 builds to debug, the conclusions that I can draw are:
The provisioning profiles in the Apple Developer Account have been set up correctly (some builds work, so can only conclude that the configuration here is right).
Successive runs of eas build can yield different results (given the same input).
Results succeed more consistently with less of our application code included (e.g. stripping back to a boilerplate project. Results fail more consistently with more of our application code included - building the app code up from scratch, we reach a tipping point where the inconsistent build output begins (though this tipping point is not definitive).
Analysing the differences between the build outputs of successful and unsuccessful runs, we see the presence of the following entitlement deep in the bundle in successful runs, but it is absent from the failed runs. No changes to the capabilities / provisioning profiles (etc) were made in between these runs:
I don’t know what’s going on, but if you’re getting builds of the exact same source code sometimes working and sometimes failing with different Xcode build logs then maybe there are inconsistencies between different build servers.
I’d try building locally, assuming you have a Mac with an up to date version of macOS and Xcode installed. Basically you just tack --local onto the eas build command. If you do that is it consistent from one build to the next?
I checked your last 2 builds and one of them was managed and the other one was bare, make sure you did not accidentally ejected (if android and ios directories exists and are not gitignored project is bare)
Thanks @wodin that’s really useful advice, and something that I can try, though it’s quite difficult to get it to fail predictably (or often enough) to determine whether I’m actually seeing consistent behaviour, or just being lucky. It might help provide a faster feedback loop on stuff though.
I definitely had very different XCode logs between the successful and failing scenarios.
Thanks @wkozyra. These most recent couple of builds were simply me trying to experiment with whether the bare workflow offered me more levers to try to diagnose the problem. All of my issues occurred with the managed workflow. I can provide two build ids for builds that behaved differently, seemingly with the same input, if that would be helpful?
@tomosframework I don’t think everyone using the onesignal plugin has this issue. So, unless you’ve figured it out already, I think we could benefit by sharing our app.config and package.json files with each other and finding commonalities.
I normally work on a PC, and that warning only happens when I prebuild or eject on a mac. So far I haven’t run a lot of builds from the mac (since its not mine), so I don’t know if the “working” builds would’ve had that warning or not, but its something I can try tomorrow.
Kind of. The “multiple entitlements files” warning would make it seem that that’s what is happening. But after the build, the OneSignalNotificationServiceExtension target has the correct entitlements, while the Project target has the overwritten default entitlements.
I tried renaming the app, which reordered the targets alphabetically. After that, the warning says its using the Project entitlements and ignoring the OneSignalNotificationServiceExtension entitlements (opposite as before). But there’s no change in the resulting build. The OneSignal entitlements end up correct, and the Project entitlements are overwritten.
@jrconsole - really sorry to be slow - it’s been difficult to find the time to repro this consistently and systematically. I’m happy to look for commonalities, if it would be mutually beneficial for our diagnoses.
We are working on support for different entitlements per target. Currently, the only reliable way is to:
eject/prebuild (and commit android and ios directory in the repo)
after prebuild you might need to fix manually the content of your entitlements files
use credentials.json or managed credentials with EXPO_NO_CAPABILITY_SYNC
The issue comes from the fact that the wrong file can be picked when:
prebuild is run on eas builder
eas-cli is updating your apple developer settings
Missing Push Capability
This error means that value is missing in apple developer portal, workaround could be here that if you add push notification entitlement to the application and extension (and regenerate profiles) it should work even if wrong entitlements file is picked
Hi @wkozyra . Thanks for the quick reply. I must admit that I’m not wholly convinced that the problem is that the wrong entitlements file is being chosen. Reason being:
For both builds that work, and builds that do not work, the extension’s entitlements file is being reported as ignored. If this isn’t the case (and the choice of entitlement file is truly random), then there’s a bug in the warning message.
Even when the capabilities are set up correctly in both entitlements files the issue still occurs (randomly).
I’m also not sure that the capabilities are being incorrectly sync’d either, as they look correct / identical before and after a working build and before and after a non-working build.
That being said, I’ve done some more testing, as follows:
Checked that the capabilities are all set up correctly in the Developer Portal.
Regenerated and downloaded the provisioning profiles to use as local credentials.
Run a prebuild before the eas build and checked the capabilities exist as expected in both the main entitlements file and the extension’s entitlements file.
Run an eas build with EXPO_NO_CAPABILITY_SYNC=1.
I have tried this three times and still get random results - 2 working builds and 1 non-working build.
9e6e59ae-8594-484b-80f2-3f29751eead2 - not working
06c611ee-bc05-4e4a-915a-0f71a4623cc4 - working
2cea1474-2d04-425b-b310-a2c5c16e178d - working
I’ve run out of options on this thread, so any further options you can provide would be really welcome.
9e6e59ae-8594-484b-80f2-3f29751eead2 - not working
what do you mean by not working, I see that build succeeded, so it is not the missing capabilities problem.
I’m also not sure that the capabilities are being incorrectly sync’d either
If you are using credentials.json then yes this is not the issue (EXPO_NO_CAPABILITY_SYNC is not necessary).
I’ve run out of options on this thread, so any further options you can provide would be really welcome.
I recommend waiting for support in manged workflow and in the meantime just using it as ejected. After you get the next successful build, do not run prebuild anymore, if results are still random after that then the issue is not related to eas.
The build always succeeds - my problem is that sometimes OneSignal reports “Missing Push Capability”, as you say, suggestive of a problem in the entitlements / capabilities that are built into the app.
Thanks for the clarity on EXPO_NO_CAPABILITY_SYNC.
I recommend waiting for support in manged workflow and in the meantime just using it as ejected.
The OneSignal plugin can work in the managed workflow, I believe, though this doesn’t work for me either.
After you get the next successful build, do not run prebuild anymore
OK - I’m happy to try running several iterations of eas build after a successful prebuild + build, to see if that has a higher success rate.
I really appreciate the help in trying to isolate the problem - this is critical, though the problem must surely reside in either EAS or in the OneSignal extension, and neither is claiming responsibility at the moment. I find it worrying that, with the exact same inputs (source code, configuration, Developer Portal configuration, EAS build parameters etc etc) the process yields different outputs. This surely warrants further investigation?