release build cannot be built locally

[konradowy]

I'm not able to build project (as a workspace with pod, both written in Swift ) with release configuration due to team ID not found.
However XCode is able to build (and archive) the above when I manually set Bundle Identifier for pods project targets.

Log snippet from Jenkins:

=== CLEAN TARGET Pods-Xxxxxxxxx OF PROJECT Pods WITH CONFIGURATION Release ===

Check dependencies
[BEROR]Code Sign error: No code signing identities found: No valid signing identities (i.e. certificate and private key pair) matching the team ID “(null)” were found.
[BEROR]CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'

The problem seems to be that 'pod install' doesn't set bundle identifier which is needed by frameworks for code written in Swift.
I'm using cocoapods 0.36.0.beta.1

[pkordal]

Hi,

Just to confirm what has been written above and emphasize importance of issue.. we cannot build any project with Release config w/o manual changes in Pods project.

Reproduction steps:

1. Create new Swift project
2. Setup Provisioning profile for Release build (->after this step Release build works perfectly)
3. Add Podfile with one of existing pods made in Swift
4. pod install
5. Open project with workspace file. Archive... (->after this step Release build does not work because of reason described above by @konradowy )

very best,
pawel

[neonichu]

Seems like Xcode just yolos through if one sets "Provisioning Profile" to automatic and even AdHoc deployment with the wildcard profile works.

To clarify, you're changing the Bundle ID from 'org.cocoapods.*' to have the same prefix as your main application to make it work for your case?

[pkordal]

Yes, we are changing Bundle ID to the main application's one + we need to manually select Provisioning profile in Pods project, also using exactly the same which has been used in main project.

[neonichu]

@kordziu There seems to be no way of inheritance for provisioning profiles, but wouldn't setting it to "Automatic" in all projects work for your case once the Bundle IDs are correct?

[pkordal]

Honestly Automatic setting does not work to me with our provisioning profile (No signing identity found), even though I build simple project (w/o cocoa pods). I assume Xcode has some troubles 'guessing' proper profile based on bundle id, maybe because it is universal (.*) one.

[konradowy]

seems like beta 2 resolved the issue.

[segiddins]

@kordziu did beta 2 fix the issue for you as well?

[pkordal]

Actually it seems problem solution I found works well also with beta 1, but it was kind of blind guess.
Maybe it is obvious (it was surprising to me) but the mandatory element of making Release build of project containing Swift made pods is to have... Development certificate in keychain. So far on Jenkins we used to have only Distribution certificates. So...

• distribution certificate/private key ONLY -> build fails
• distribution certificate/private key + developer certificate/private key -> successful build.

Additionally - what is a bit surprising to me - when you build app with command line and do not define explicitly SDK to be 'iphoneos', products generated in Derived Data are :
-> main app's project is built with iphoneos sdk
-> Pods project is being built with iphonesimulator sdk.

What is now new blocker for us after main issue is solved is that when xcodebuild gets defined output directory as a param (CONFIGURATION_BUILD_DIR=), there are problems with Pods-frameworks.sh and install_framework() function. In mentioned case (custom output build dir) local source is not "${BUILT_PRODUCTS_DIR}/Pods/$1" but source="${BUILT_PRODUCTS_DIR}/$1". After removing manually Pods from path all works fine.

[neonichu]

I guess we could cover for the case where users manually set CONFIGURATION_BUILD_DIR, but we have to keep in mind that it can wreak havoc when multiple targets are involved with the same Pods. In that case, multiple targets will produce the same output file which probably results in 💥

[pkordal]

I am aware Cocoapods are not about Jenkins and CI, but in the end CI is important element of each iOS project. Not having CONFIGURATION_BUILD_DIR case handled would make building any project containing Swift pods big pain.

[neonichu]

@kordziu I agree, my comment was more about considering the implications of this.

[bassrock]

I would say a signing issue occurs just like #3156

[neonichu]

The code-signing issue has been solved by the OP and there's already a more detailed issue on the problem with scoping the output directories for frameworks in #3095 => we can close this.