release build cannot be built locally #3063

Closed
konradowy opened this Issue Jan 22, 2015 · 13 comments

Projects

None yet

7 participants

@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

@orta orta added the Frameworks label Jan 24, 2015
@pkordal
pkordal commented Jan 26, 2015

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 neonichu added this to the 0.36.0 milestone Jan 26, 2015
@neonichu
Member

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
pkordal commented Jan 26, 2015

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
Member

@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
pkordal commented Jan 26, 2015

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
Member

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

@pkordal
pkordal commented Feb 16, 2015

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
Member

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
pkordal commented Feb 16, 2015

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
Member

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

@bassrock

I would say a signing issue occurs just like #3156

@kylef kylef added the t2:defect label Feb 21, 2015
@neonichu
Member

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.

@neonichu neonichu closed this Feb 24, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment