We don’t use Jenkins but I’ve seen this in our build automation before. Here’s how we solved it:
1) Create your build Keychain. This will contain the private key/certificate used for codesigning:
security create-keychain -p [keychain_password] MyKeychain.keychain
The keychain_password is up to you. You’ll use this later to unlock the keychain during the build.
2) Import the private key (*.p12) for your CodeSign identity:
security import MyPrivateKey.p12 -t agg -k MyKeychain.keychain -P [p12_Password] -A
The key here is the “-A” flag. This will allow access to the keychain without warning. This is why you’re seeing the “User interaction is not allowed” error. If you were attempting this build via the Xcode UI, this is the point where it would prompt you to “Allow access” to your keychain.
3) However you’re saving the Keychain (e.g.: checking it in to source control), make sure it’s writeable and executable by your build user.
When you’re ready to build, add the following prior to running xcodebuild:
# Switch keychain
security list-keychains -s "/path/to/MyKeyhain.keychain"
security default-keychain -s "/path/to/MyKeychain.keychain"
security unlock-keychain -p "[keychain_password]" "/path/to/MyKeychain.keychain"
If you’re running locally, you may want to add something at the end of your build script that switches back to the login keychain (~/Library/Keychains/login.keychain), e.g.:
# Switch back to login keychain
security list-keychains -s "~/Library/Keychains/login.keychain"
security default-keychain -s "~/Library/Keychains/login.keychain"
Give that a try. We create a separate Keychain for each identity we use (our own plus builds on behalf of customers). In our company’s case, we have both an AppStore and Enterprise account. This can result in naming conflicts while codesigning (e.g.: both accounts resolve to “iPhone Distribution: ACME Corporation”). By keeping these identities in separate keychains we avoid this conflict.