Cocoapods: EXPANDED_CODE_SIGN_IDENTITY: unbound variable

[djbe]

• [x] I've read and understood the *CONTRIBUTING guidelines and have done my best effort to follow.

Report

What did you do?

Run pod install and tried to run my (SwiftGen) project tests, using CocoaPods 1.5.0.

What did you expect to happen?

Install all pod dependencies correctly and have a buildable (testable) project.

What happened instead?

I get the following build error for the SwiftGenKit unittests:

PhaseScriptExecution [CP]\ Embed\ Pods\ Frameworks
...
rsync --delete -av --filter P .*.?????? --filter "- CVS/" --filter "- .svn/" --filter "- .git/" --filter "- .hg/" --filter "- Headers" --filter "- PrivateHeaders" --filter "- Modules" "/.../Build/Products/Debug/Kanna/Kanna.framework" "/.../Build/Products/Debug/SwiftGenKit UnitTests.xctest/Contents/Frameworks"
building file list ... done

sent 341 bytes received 20 bytes 240.67 bytes/sec
total size is 486148 speedup is 1346.67
/.../SwiftGen/Pods/Target Support Files/Pods-SwiftGenKit-SwiftGenKit UnitTests/Pods-SwiftGenKit-SwiftGenKit UnitTests-frameworks.sh: line 104: EXPANDED_CODE_SIGN_IDENTITY: unbound variable
Command PhaseScriptExecution failed with a nonzero exit code

Now the thing of real note is that everything works just fine in CocoaPods 1.4. When I roll back the gem to 1.4, and run bundle exec pod install, everything works fine. It's only when I run bundle exec pod install with 1.5 that the error mentioned above appears.

Note: the currently generated workspace/pod-project on SwiftGen is using CocoaPods 1.4, otherwise our CI would break and the project wouldn't work for other developers.

CocoaPods Environment

Stack

   CocoaPods : 1.5.0
        Ruby : ruby 2.3.7p456 (2018-03-28 revision 63024) [x86_64-darwin17]
    RubyGems : 2.5.2.3
        Host : Mac OS X 10.13.4 (17E202)
       Xcode : 9.3 (9E145)
         Git : git version 2.15.1 (Apple Git-101)
Ruby lib dir : /Users/davidjennes/.rbenv/versions/2.3.7/lib
Repositories : bitbucket-appwise-podspecs - [email protected]:appwise/appwise-podspecs.git @ 7695d3238f55b0574fc2fdf6f2e1d324a31a6465
               master - https://github.com/CocoaPods/Specs.git @ a47db189c1ef51eb045aeac0ba231fddc81ce5f4

Installation Source

Executable Path: /Users/davidjennes/.rbenv/versions/2.3.7/bin/pod

Plugins

cocoapods-deintegrate : 1.0.2
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.0.0
cocoapods-trunk       : 1.3.0
cocoapods-try         : 1.1.0

Podfile

platform :osx, '10.9'
use_frameworks!

raise 'Please use bundle exec to run the pod command' unless defined?(Bundler)

def common_pods
  podspec :path => 'SwiftGenKit.podspec'
  pod 'SwiftLint', '~> 0.25'
end

target 'swiftgen' do
  common_pods
  pod 'Commander', '~> 0.8'
  pod 'StencilSwiftKit', '~> 2.3'
  pod 'Yams', '~> 0.3'

  target 'SwiftGen UnitTests' do
    inherit! :complete
  end

  target 'Templates UnitTests' do
    inherit! :complete
  end
end

target 'SwiftGenKit' do
  common_pods

  target 'SwiftGenKit UnitTests' do
    inherit! :complete
    pod 'Yams', '~> 0.3'
  end
end

post_install do |installer|
  swift3_pods = %w(Stencil)
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings['SWIFT_VERSION'] = '3.2' if swift3_pods.include?(target.name)
    end
  end
end

Project that demonstrates the issue

https://github.com/SwiftGen/SwiftGen

[djbe]

Note: I also tried adding https://michiganlabs.com/ios/development/2015/11/30/code-sign-error-building-cocoapods-framework-targets/, but that didn't change anything.

[segiddins]

cc @keith

[keith]

I'll look at this soon

[djbe]

I've added a branch test/cocoapods-1.5 that shows how it's broken when installing with 1.5. It only has 1 commit, the result of running pod install.

[segiddins]

It's from the fact that we now have set -o nounset in generated scripts

[keith]

Interesting so if you enable "show environment variables" on the build script where this fails you see this:

export EXPANDED_CODE_SIGN_IDENTITY=-
export EXPANDED_CODE_SIGN_IDENTITY_NAME=-

But then if you add an env to the script this doesn't appear at all. I guess we need to no-op this one as well..

[keith]

Here's a PR allowing this https://github.com/CocoaPods/CocoaPods/pull/7720

[djbe]

I can confirm that applying the change from the PR fixes the issue 👍 (I did have to apply it for each test target)

[dnkoutso]

Closing this since https://github.com/CocoaPods/CocoaPods/pull/7720 landed.

[wanqingrongruo]

sorry, I can't understand what should I do...
I have updated cocoapods to 1.6.0.beta.1, but the error Pods-xxx-frameworks.sh: line 128: ARCHS[@]: unbound variable also exsits...
Looking forward to reply. thx

[paulb777]

Any workarounds for the Xcode 10, CocoaPods 1.5.x and macOS combination?

[djbe]

@paulb777 manually edit the generated .sh script file to add the :- where needed (see https://github.com/CocoaPods/CocoaPods/pull/7720/files).

That, or update to 1.6.0 beta.

[soffes]

Can confirm 1.6.0.beta.1 fixes this on Mojave

[iwasrobbed-ks]

1.6.0.beta.1 unfortunately breaks other things (different Swift versions between targets) so manually editing for now 👎Definitely prefer to not force people to use beta builds versus issuing a patch release

[fbeeper]

as a quick workaround, instead of modifying the autogenerated code, I think you may be able to run jazzy after predefining those variables to empty strings (or any valid signing configuration):

export EXPANDED_CODE_SIGN_IDENTITY=""
export EXPANDED_CODE_SIGN_IDENTITY_NAME=""
export EXPANDED_PROVISIONING_PROFILE=""
jazzy <your parameters>

[shayneoneill]

I've had the same problem, those export lines at the top of the script seem to do the job, although to be brutally honest, I'm not sure what the job is (other than "make it work"). Would it be wise to assume that when I get around to setting my app for code signing etc (Its a macos, not ios app) I should take those out?

[fbeeper]

@shayneoneill I was referring to a specific use case where codesigning is not necessary (generating documentation with jazzy). However, if your build job requires it to generate a signed application, you probably will need to be passing non-empty codesign/provisioning parameters. Hope this note helps you.

[Buju77]

Is it possible to back port the simple fix of adding 2 chars ':-' in #7720 to 1.5.x and release it as 1.5.4?

Because we are having issues building our app on our CI with Xcode 10 GM + CP 1.5.3.

We just tried adding those 2 chars into the script and then our CI is working fine again. But always having to edit the script is obviously not scaleable.

We are not confident and ready yet to use 1.6.0 beta right now. Or somebody else provide a suitable workaround? Or will releasing this fix as 1.5.4 have any side effects for current users?

[khaptonstall]

Currently able to work around this on Xcode 10, Cocoapods 1.5 by adding the following User-Defined Settings to my project:

EXPANDED_CODE_SIGN_IDENTITY="-"
EXPANDED_CODE_SIGN_IDENTITY_NAME="-"

[Buju77]

@khaptonstall but are you still then able to create a distribution build with those settings with proper code signing?

[Buju77]

ok so here is our current workaround:

• we have our own Gems server running internally for all our own internal gems
• I created a new Cocoapods version called 1.5.3.1-internal with the change of only adding these 2 characters like in the PR #7720 and uploaded that Gem version to our own Gems server
• as we have Gemfiles in our iOS projects, we could simply use that 1.5.3.1-internal version
• everything seems to work as far as we can tell ;)

[yvbeek]

Currently able to work around this on Xcode 10, Cocoapods 1.5 by adding the following User-Defined Settings to my project:

EXPANDED_CODE_SIGN_IDENTITY="-"
EXPANDED_CODE_SIGN_IDENTITY_NAME="-"

@khaptonstall I've tried this, but it doesn't work for my library. I still get the same error.

[DavidPotter]

We are dead in the water at this point until this fix is deployed. We publish internal podspecs to a private repo. Due to this issue, we are unable to publish anymore. What is the possibility of publishing a 1.5.3.1 or a 1.5.4 with just this fix like @Buju77 suggested?

[dnkoutso]

There is 1.6.0.beta.2 and beta.1 that include this fix.

You can also try bundler and point to the SHA or temporarily fork CocoaPods and apply the patch manually until 1.6.0 stable is out if you do not want to use the beta.

[DavidPotter]

Thanks @dnkoutso. I was able to install 1.6.0 beta 2 and that solved the problem for now. Looking forward to an official release of 1.6.0.

[rivsat]

I have integrated Firebase and GoogleTagManager into my iOS app target using Cocoapods. When I build my target, Xcode constantly gives me error:

Showing Recent Messages
PhaseScriptExecution [CP]\ Embed\ Pods\ Frameworks 

mkdir -p /Users/xxx.xxx/Library/Developer/Xcode/DerivedData/MyApp-enzvpdzsyhjszqbnwiclnpszlyri/Build/Products/Debug-iphonesimulator/MyApp.app/Frameworks


/Users/xxx.xxx/Projects/MyApp/Applications/MyApp/Pods/Target Support Files/Pods-MyApp/Pods-MyApp-frameworks.sh: line 43: source: unbound variable


Command /bin/sh failed with exit code 1

So as suggested, do I replace all occurrences of ${source} with ${source:-} in Pods-Project-frameworks.sh file ?

[amorde]

@rivsat the fix for this issue was released with CocoaPods 1.6.0 - if you're on an older version, please try updating and see if it fixes the issue for you.

If you're still experiencing this on the latest version, a new issue with steps to reproduce would be super helpful!

[nickenchev]

I'm still getting this error when running xcodebuild -arch i386 -sdk iphonesimulator13.2

Pods/Target Support Files/Pods-Trigma/Pods-Trigma-frameworks.sh: line 43: source: unbound variable

Cocoapods 1.9.0

Removed Pods directory and recreated with latest 1.9.0. Still seeing this error.

[amorde]

@nickenchev as I mentioned above your comment, if you're still experiencing this on the latest version of CocoaPods, please open a new issue with a reproducible sample so we can help fix this. Thanks!

[corners-summer]

I have encountered the same problem. Have you finally solved this problem? @nickenchev