Login credentials don't appear to 'stick'.
biddster opened this issue · comments
As part of a TeamCity build, I'm downloading a specific profile. The build runs as a specific user. From the command line, logged in as that same user, I can download the profile. As part of the build I get the error below. I'm sure the actual problem is that login is being called and a prompt for username is being presented. Just prior to the ios profiles:download command, I unlock the login keychain for the build user.
I realise this is probably not a bug in cupertino, but I'm stuck and don't know where else to ask. Thanks for any help you can provide.
[12:54:58]+ ios profiles:download --type distribution 'Development Build - Ad Hoc' --trace
[12:55:01]/Library/Ruby/Gems/2.0.0/gems/highline-1.6.21/lib/highline/question.rb:414:in `remove_whitespace': undefined method `strip' for nil:NilClass (NoMethodError)
[12:55:01] from /Library/Ruby/Gems/2.0.0/gems/highline-1.6.21/lib/highline.rb:867:in `get_line'
[12:55:01] from /Library/Ruby/Gems/2.0.0/gems/highline-1.6.21/lib/highline.rb:885:in `get_response'
[12:55:01] from /Library/Ruby/Gems/2.0.0/gems/highline-1.6.21/lib/highline.rb:260:in `ask'
[12:55:01] from /Library/Ruby/Gems/2.0.0/gems/cupertino-1.3.0/lib/cupertino/provisioning_portal/helpers.rb:19:in `username'
[12:55:01] from /Library/Ruby/Gems/2.0.0/gems/cupertino-1.3.0/lib/cupertino/provisioning_portal/agent.rb:374:in `login!'
[12:55:01] from /Library/Ruby/Gems/2.0.0/gems/cupertino-1.3.0/lib/cupertino/provisioning_portal/agent.rb:51:in `block in get'
[12:55:01] from /Library/Ruby/Gems/2.0.0/gems/cupertino-1.3.0/lib/cupertino/provisioning_portal/agent.rb:44:in `times'
[12:55:01] from /Library/Ruby/Gems/2.0.0/gems/cupertino-1.3.0/lib/cupertino/provisioning_portal/agent.rb:44:in `get'
[12:55:01] from /Library/Ruby/Gems/2.0.0/gems/cupertino-1.3.0/lib/cupertino/provisioning_portal/agent.rb:183:in `list_profiles'
[12:55:01] from /Library/Ruby/Gems/2.0.0/gems/cupertino-1.3.0/lib/cupertino/provisioning_portal/commands/profiles.rb:53:in `block (3 levels) in <top (required)>'
[12:55:01] from /Library/Ruby/Gems/2.0.0/gems/cupertino-1.3.0/lib/cupertino/provisioning_portal/helpers.rb:58:in `try'
[12:55:01] from /Library/Ruby/Gems/2.0.0/gems/cupertino-1.3.0/lib/cupertino/provisioning_portal/commands/profiles.rb:53:in `block (2 levels) in <top (required)>'
[12:55:01] from /Library/Ruby/Gems/2.0.0/gems/commander-4.2.1/lib/commander/command.rb:180:in `call'
[12:55:01] from /Library/Ruby/Gems/2.0.0/gems/commander-4.2.1/lib/commander/command.rb:180:in `call'
[12:55:01] from /Library/Ruby/Gems/2.0.0/gems/commander-4.2.1/lib/commander/command.rb:155:in `run'
[12:55:01] from /Library/Ruby/Gems/2.0.0/gems/commander-4.2.1/lib/commander/runner.rb:421:in `run_active_command'
[12:55:01] from /Library/Ruby/Gems/2.0.0/gems/commander-4.2.1/lib/commander/runner.rb:81:in `run!'
[12:55:01] from /Library/Ruby/Gems/2.0.0/gems/commander-4.2.1/lib/commander/delegates.rb:8:in `run!'
[12:55:01] from /Library/Ruby/Gems/2.0.0/gems/commander-4.2.1/lib/commander/import.rb:10:in `block in <top (required)>'
Hmm, looks like it was our build machine. A power failure had corrupted something, we've restored it back to just before the power failure and it's fine again.
