I’m receiving a “Permission denied” when trying to run the pipeline after successfully compiling the app for ios. It’s failing when trying to execute a bundle react native script (which apparently doesn’t exist before the build because I can’t use a chmod command to mark it as executable) during the linking process. I’m at my wits’ end with this issue here and don’t really know what else to try anymore. The specific error is the following:
No, unfortunately not yet. I did some more digging and have tried most of the things several days of googling brought up but so far I still haven’t found a solution. (Also doesn’t help that a lot of the suggested solutions are just restarting your pc and the like)
The pod install command is being run. I also don’t get any error messages regarding keychain or password mismatch. I can see the tmp_keychain as well as it’s password being set in the summary for match. It all seems to work flawlessly until I reach the step “Run fastlane to build iOS”. The only additional info it’s giving me is a “permission denied”:
▸ /bin/sh -c /Users/distiller/Library/Developer/Xcode/DerivedData/…/Mattermost.build/Debug-iphoneos/Mattermost.build/Script-00DD1BFF1BD5951E006B06BC.sh
▸ /Users/distiller/Library/Developer/Xcode/DerivedData/…/Mattermost.build/Debug-iphoneos/Mattermost.build/Script-00DD1BFF1BD5951E006B06BC.sh: line 2: ./bundleReactNative.sh: Permission denied
▸ Command PhaseScriptExecution failed with a nonzero exit code
changing the export option to Release instead of Debug didn’t change anything. I’ve also tried reverting back to an older version (13.2) of Xcode but it still fails at the same step, it just doesn’t show any additional info, so the line about “permission denied” is missing with the older version.
I’ve also tried manually running pod update but that also didn’t help. The only thing I haven’t tried yet is the “try unlocking and locking your keychain in Xcode” because that doesn’t apply to CircleCI (unless I’m missing something really obvious).
The Fastfile being used is also the one from the official Mattermost Github.
It’s weird because I was able to build it locally just fine with mattermost version 2.0 so I’m going to try that out next and post an update here in case it works.
Also thank you for forwarding the issue @agriesser!
Ah, OK, so you’re trying to build eht 1.x version and not the 2.x? I don’t think that this is still possible, lots of dependencies broke over the last few months from what I read in the community and people are struggling to compile it and that’s where Mattermost always suggests to go with the 2.0 build since this is the new major version of the mobile app anyways.
Is there a specific reason why you need the 1.x release?
Ah no, I think there’s a misunderstanding here, I initally managed to build it while version 2.0 was still the newest one, but currently I’m trying to get 2.3 (well, now 2.4) to work.
I managed to finally build it! As always when it’s taking this long to fix something it was something super obvious. I assumed that the bundleReactNative.sh didn’t exist before the build but it was just sitting in the ios folder instead, so I could just use ‘chmod +x bundleReactNative.sh’ command inside the right folder (as well as ‘chmod +x uploadDebugSymbols.sh’). I stumbled upon them when setting up the build for Mattermost 2.4 when I ran into some cocoapod issues during the ‘Getting cocoapods dependencies’ step:
[!] CocoaPods could not find compatible versions for pod “Rudder”:
In snapshot (Podfile.lock):
Rudder (= 1.14.0, ~> 1.13)
In Podfile:
RNRudderSdk (from ../node_modules/@rudderstack/rudder-sdk-react-native) was resolved to 1.7.0, which depends on
Rudder (~> 1.13)
I noticed there was an update to the Podfile.lock mere minutes ago when I ran into this so I tried manually updating it. Deleting the Podfile.lock from my repository triggered a circleci build and it worked just fine and created a cache so now I’m not running into this issue anymore (not sure if it will happen again once it’s not relying on the cache). I could also do “pod update Rudder” before pod install as a workaround, not really sure what the proper way of handling this would have been. So yeah, I think the issue has been resolved, thank you again for reaching out @agriesser!