我们的自动化版本正在Jenkins上运行。构建本身在从属服务器上运行,并且从属服务器通过SSH执行。
我收到一个错误:
00:03:25.113 [codesign-app] build/App.app: User interaction is not allowed.
我已经尝试了到目前为止在其他帖子中看到的所有建议:
在所有情况下,我都会遇到相同的错误。
为了诊断问题,我尝试在本地终端上运行“securityunlock-keychain”命令,发现该命令实际上并没有解锁钥匙链- 如果我查看“钥匙串访问”,则锁符号仍然存在。无论是在命令行上通过密码还是让我提示输入密码,都是这种情况。使用GUI解锁相同的钥匙串会提示我输入密码,然后将其解锁。另外,如果我运行“ security lock-keychain”, 则 在运行命令后我 会 立即看到密钥锁。这使我认为解锁钥匙串实际上不起作用。我在Lion(我们用于构建奴隶)和Mavericks(我正在开发)上遇到相同的行为。
接下来,我尝试将-v添加到所有安全命令中:
list-keychains "-d" "system" "-s" "/Users/tester/.secret/App.keychain" Listing keychains to see if it was added: (( "/Library/Keychains/System.keychain" )) unlock-keychain "-p" "**PASSWORD**" "/Users/tester/.secret/App.keychain" build/App.app: User interaction is not allowed.
由此看来,列表钥匙串是行不通的。也许都不行。:/
解决方案很有趣-在launchctl中将“SessionCreate”设置为true。但是我不是在主服务器上构建的-我的构建过程是从从属构建计算机上的SSH开始的。在运行“SessionCreate”时,也许有一种命令行方式可以执行launchctl在做什么?
好吧,我想我今天要回答我自己的问题,因为在经过两天半的时间刺伤之后,我尝试过的其中一件事情似乎奏效了。我现在要退出它,希望它能继续工作。
从本质上讲,它似乎归结为-dsystem无法实际工作。因此,应该对此处周围其他问题的很多答案进行更新以反映这一点。
-dsystem
security -v list-keychains -s "$KEYCHAIN" "$HOME/Library/Keychains/login.keychain" security list-keychains # so we can verify that it was added if it fails again security -v unlock-keychain -p "$KEYCHAIN_PASSWORD" "$KEYCHAIN" codesign --sign "$SIGNER_IDENTITY" --force --signature-size 9600 \ --resource-rules src/AppResourceRules.plist --timestamp --verbose \ "$APP"