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
Closed

release build cannot be built locally #3063

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

Comments

@konradowy
Copy link

@konradowy konradowy 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

@pkordal
Copy link

@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
Copy link
Member

@neonichu neonichu 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
Copy link

@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
Copy link
Member

@neonichu neonichu 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
Copy link

@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
Copy link
Author

@konradowy konradowy commented Feb 13, 2015

seems like beta 2 resolved the issue.

@segiddins
Copy link
Member

@segiddins segiddins commented Feb 14, 2015

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

@pkordal
Copy link

@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
Copy link
Member

@neonichu neonichu 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
Copy link

@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
Copy link
Member

@neonichu neonichu commented Feb 16, 2015

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

@bassrock
Copy link

@bassrock bassrock commented Feb 21, 2015

I would say a signing issue occurs just like #3156

@neonichu
Copy link
Member

@neonichu neonichu 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants