Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

release build cannot be built locally #3063

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

Comments

Projects
None yet
7 participants
@konradowy
Copy link

commented Jan 22, 2015

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

commented Jan 26, 2015

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

commented Jan 26, 2015

@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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Author

commented Feb 13, 2015

seems like beta 2 resolved the issue.

@segiddins

This comment has been minimized.

Copy link
Member

commented Feb 14, 2015

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

@pkordal

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

commented Feb 16, 2015

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

commented Feb 16, 2015

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

@bassrock

This comment has been minimized.

Copy link

commented Feb 21, 2015

I would say a signing issue occurs just like #3156

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

@neonichu

This comment has been minimized.

Copy link
Member

commented Feb 24, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.