Jerome, we use a setup like you describe however we do it slightly differently.

1) We specify a keychain and identity in the target build settings (actually 
via an xcconfig) like this

Debug:
CODE_SIGN_IDENTITY = iPhone Developer
OTHER_CODE_SIGN_FLAGS = --keychain=$HOME/Library/Keychains/Panic.keychain

For most of our targets and configurations we can leave the profile set to 
Automatic. Xcode sometimes gets confused and uses our app store profile with an 
ad-hoc target so we hard code that profile in the build settings.

We are not tearing down and building up the keychains each time like you are 
though. The Panic keychain is kept in sync amongst our build machines and 
rarely changes.

I should add that I personally have a few other team-specific keychains and my 
projects don’t get confused about which signing identity to use because of the 
use of --keychain.


James




> On Dec 16, 2014, at 3:02 AM, Jerome Lacoste <[email protected]> wrote:
> 
> Hello,
> 
> I am trying to have, for every build job, a different keychain with
> the proper identities in it.
> 
> Given my previous email about me not having managed to find an atomic
> way to modify the search list of keychains, I tried to use xcodebuild
> WITHOUT using list-keychains -s
> 
> And I use OTHER_CODE_SIGN_FLAGS to specify the keychain.
> 
> But xcodebuild fails because of "No codesigning identities found".
> 
> 
> Details:
> 
> 1. create a keychain
> 2. unlock it
> 3. unset timeout (for test purposes)
> 4. import signing identities into it
> 5. copy the developer profiles into the proper location
> 
> security delete-keychain other_keychain
> security create-keychain -p 1111 other_keychain
> security unlock-keychain -p 1111 other_keychain
> security set-keychain-settings other_keychain
> 
> security import ..../0123456789.p12 -k other_keychain -P THEPASSWORD
> -T /usr/bin/codesign other_keychain
> 
> cp YYYYYYY.mobileprovision  ~/Library/MobileDevice/Provisioning\ Profiles/
> 
> and then that's all. No modification of the list of known keychains.
> 
> But then xcodebuild now fails at start because it cannot find the
> signing identities.
> 
> /usr/bin/xcodebuild -verbose -target Unity-iPhone -configuration
> Release build CONFIGURATION_BUILD_DIR=.......
> 'CODE_SIGN_IDENTITY=XXXXXXX PROVISIONING_PROFILE=YYYYYYY
> "OTHER_CODE_SIGN_FLAGS='--keychain
> ~/Library/Keychains/other_keychain'"
> 
> 
> Check dependencies
> Code Sign error: No codesigning identities found: No codesigning
> identities (i.e. certificate and private key pairs) that match the
> provisioning profile specified in your build settings (“NAME OF MY
> PROFILE”) were found.
> CodeSign error: code signing is required for product type
> 'Application' in SDK 'iOS 8.1
> 
> Yet this works:
> 
> /usr/bin/security find-certificate -a -c "XXXXXXXXXXXX" -Z
> ~/Library/Keychains/other_keychain | grep ^SHA-1
> 
> SHA-1 hash: 0123456789
> 
> xcodebuild doesn't support a -keychain or --keychain argument.
> 
> So I wonder it the "Check dependencies" step is a bit overzealous and
> forget to check the OTHER_CODE_SIGN_FLAGS argument.
> 
> Is this a bug ?
> Is there a way to get xcodebuild to work WITHOUT modifying the default
> list of keychains ?
> 
> If not, should I conclude that one shouldn't really try to make per
> build process isolated keychains environments (for both security and
> avoiding the potential threading issue caused by the non atomic adding
> of keychains) ? Should I consider having one system user per job
> instead ?
> 
> Thanks!
> 
> Jerome
> 
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list      ([email protected])
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/xcode-users/hello%40jmoore.me
> 
> This email sent to [email protected]

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to