Резюме:
Настройка Jenkins на OS X была значительно упрощена с помощью последнего установщика (с 1.449 по 9 марта 2012 г.), однако управление процессом подписи кода все еще очень сложно без прямого ответа.
Мотивация:
Запустите безглавой CI-сервер, который следует общим рекомендациям по запуску служб в OS X (Некоторые из них объясняются здесь на простом языке).
Фон:
- 12 октября 2009 г. - Как автоматизировать сборки iPhone с помощью Hudson
- 15 июня 2011 г. - Дженкинс на Mac OS X; git w/ssh открытый ключ
- 23 июня 2011 г. - Непрерывное развертывание приложений iOS с Jenkins и TestFlight
- 26 июля 2011 г. - Отсутствие сертификатов и ключей в цепочке ключей при использовании Jenkins/Hudson в качестве непрерывной интеграции для разработки iOS и Mac
- 30 августа 2011 г. - Файл обеспечения Xcode Provisioning не найден с Jenkins
- 20 сентября 2011 г. - Как настроить Jenkins CI на Mac
- 14 сентября 2011 г. - Получение Jenkins на Mac
- 12 ноября 2011 г. - Howto: установите Jenkins на OS X и заставьте его создавать материалы Mac
- 23 января 2012 г. - Изменения в предстоящем установщике Jenkins OSX
- 7 марта 2012 г. - Спасибо за использование установщика OSX
процесс:
Установите Jenkins CI через OS X установочный пакет. Для шага "Тип установки" нажмите кнопку "Настроить" и выберите "Начать при загрузке как" Дженкинс ".
Обсуждение:
Наивное ожидание на этом этапе состояло в том, что проект свободного стиля с конструкцией script xcodebuild -target MyTarget -sdk iphoneos должен работать. Как указано в заголовке этого сообщения, он не выполняет и не выполняет следующие действия:
Code Sign error: The identity 'iPhone Developer' doesn't match any valid certificate/private key pair in the default keychain
Достаточно очевидно, что должно произойти - вам нужно добавить действительный сертификат подписи кода и закрытый ключ в цепочку ключей по умолчанию. Изучая, как это сделать, я не нашел решения, которые не открывают систему до некоторой степени уязвимости.
Проблема 1: Отсутствие брелка по умолчанию для демона денкинсов
sudo -u jenkins security default-keychain
... дает "Невозможно найти брелок по умолчанию"
Как указано ниже Ivo Dancet, UserShell по умолчанию установлен на /usr/bin/false для денкинса (я думаю, что это функция, не ошибка); следуйте его ответам, чтобы изменить UserShell на bash. Затем вы можете использовать sudo su jenkins, чтобы войти в систему как пользователь jenkins и получить приглашение bash.
-
sudo su jenkins -
cd ~/Library -
mkdir Keychains -
cd Keychains -
security create-keychain <keychain-name>.keychain -
security default-keychain -s <keychain-name>.keychain
Хорошо, отлично. Теперь у нас есть брелок по умолчанию; пусть двигаться дальше? Но, во-первых, почему мы даже потрудились создать брелок по умолчанию?
Почти все ответы, предложения или беседа, которые я читал в ходе исследования, предполагают, что нужно просто выталкивать сертификаты и ключи для подписания кода в системный брелок. Если вы запустите security list-keychains как проект свободного стиля в Jenkins, вы увидите, что единственная доступная цепочка ключей - это системный брелок; Я думаю, что там, где большинство людей придумали поставить свой сертификат и ключ там. Но это просто кажется очень плохой идеей - особенно учитывая, что вам нужно создать простой текст script с паролем, чтобы открыть цепочку ключей.
Проблема 2: Добавление сертификатов подписи кода и закрытого ключа
Вот где я действительно начинаю брезгливо. У меня есть ощущение, что я должен создать новый открытый/закрытый ключ, уникальный для использования с Дженкинсом. Мой мыслительный процесс заключается в том, что демон jenkins скомпрометирован, тогда я могу легко отменить сертификат в Apple Provisioning Portal и создать еще один открытый/закрытый ключ. Если я использую тот же ключ и сертификат для моей учетной записи пользователя и Jenkins, значит, это означает больше хлопот (ущерб?), Если атакует служба jenkins.
Указывая на Simon Urbanek answer, вы будете разблокировать брелок из script с помощью обычного текстового пароля. Кажется безответственным сохранить что-либо, кроме "одноразовых" сертификатов и ключей в брелках дзенкин-демона.
Меня очень интересует любое обсуждение обратного. Я слишком осторожен?
Чтобы создать новый CSR как демон дженкинсов в терминале, я сделал следующее...
-
sudo su jenkins -
certtool r CertificateSigningRequest.certSigningRequestВам будет предложено следующее (большинство из них я получил обоснованные догадки при правильном ответе, у вас есть лучшее понимание? Пожалуйста, поделитесь.)...- Введите метку ключа и сертификата:
- Выберите алгоритм:
r(для RSA) - Введите размер ключа в битах:
2048 - Выбор алгоритма подписи:
5(для MD5) - Введите строку запроса:
- Затем куча вопросов для RDN
- Отправьте созданный файл CSR (CertificateSigningRequest.certSigningRequest) на портал Apple Provisioning Portal под новым идентификатором Apple
- Утвердить запрос и загрузить файл .cer
-
security unlock-keychain -
security add-certificate ios_development.cer
Это делает нас на один шаг ближе...
Проблема 3: Профилирование и разблокировка брелка
Я сделал специальный профиль обеспечения в портале Provisioning Portal только для использования с CI в надежде, что если что-то случится, я сделаю удар немного меньшим. Лучшая практика или слишком осторожная?
-
sudo su jenkins -
mkdir ~/Library/MobileDevice -
mkdir ~/Library/MobileDevice/Provisioning\ Profiles - Переместите профиль настройки, который вы настроили на портале Provisioning Portal, в эту новую папку. Теперь мы находимся в двух шагах от возможности запускать xcodebuild из командной строки как jenkins, и это значит, что мы также близки к возможности запуска JS-версий JI-CIN.
-
security unlock-keychain -p <keychain password> -
xcodebuild -target MyTarget -sdk iphoneos
Теперь мы получаем успешную сборку из командной строки при входе в систему как демон дженкинсов, поэтому, если мы создадим проект в свободном стиле и добавим эти последние два шага (# 5 и # 6 выше), мы сможем автоматизировать здание нашего проекта iOS!
Это может быть необязательно, но я чувствовал, что лучше настроить jenkins UserShell на /usr/bin/false после того, как я успешно получил всю эту настройку. Я параноик?
Проблема 4: брелок по умолчанию все еще недоступен!
(EDIT: я опубликовал изменения на свой вопрос, перезагрузился, чтобы убедиться, что мое решение было на 100%, и, конечно, я не сделал ни одного шага)
Даже после всех вышеперечисленных шагов вам нужно будет модифицировать Plunch Launch Daemon в /Library/LaunchDaemons/org.jenkins-ci.plist, как указано в этом ответе. Обратите внимание, что это также ошибка openrdar.
Он должен выглядеть так:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>EnvironmentVariables</key>
<dict>
<key>JENKINS_HOME</key>
<string>/Users/Shared/Jenkins/Home</string>
</dict>
<key>GroupName</key>
<string>daemon</string>
<key>KeepAlive</key>
<true/>
<key>Label</key>
<string>org.jenkins-ci</string>
<key>ProgramArguments</key>
<array>
<string>/bin/bash</string>
<string>/Library/Application Support/Jenkins/jenkins-runner.sh</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>UserName</key>
<string>jenkins</string>
<!-- **NEW STUFF** -->
<key>SessionCreate</key>
<true />
</dict>
</plist>
С этой настройкой я также рекомендую Xcode plugin для Jenkins, что упрощает настройку xcodebuild script. На этом этапе я также рекомендую прочитать man-страницы для xcodebuild - черт возьми, вы сделали это до сих пор в терминале, правильно?
Эта настройка не идеальна, и любые советы или прозрения очень ценятся.
Мне было трудно выбрать "правильный" ответ, так как то, что я придумал для решения моей проблемы, было сборником почти каждого ввода. Я пытался дать всем по крайней мере досрочное голосование, но присудил ответ Саймону, потому что он в основном отвечал на исходный вопрос. Кроме того, Сами Тикка заслуживает большого уважения за свои усилия, заставляя Дженкинса работать AppleScript как обычное приложение OS X. Если вы заинтересованы только в том, чтобы Jenkins быстро и быстро продвигался в вашей пользовательской сессии (то есть не как безголовый сервер), его решение намного больше похоже на Mac.
Я надеюсь, что мои усилия заткнут дальнейшую дискуссию и помогут следующей бедной душе, которая приходит, думая, что они могут получить настройку Jenkins CI для своих проектов iOS в выходные из-за всех замечательных вещей, которые они слышали об этом.
Обновление: 9 августа 2013 г.
С таким количеством фаворитов и фаворитов, я думал, что вернусь к этому 18 месяцев спустя с некоторыми краткими уроками.
Урок 1: Не подвергайте Дженкинса публичному интернету
На WWDC 2012 года я взял этот вопрос инженерам Xcode и OS X Server. Я получил какофонию "не делай этого!". от кого я спросил. Все они согласились с тем, что процесс автоматической сборки был отличным, но сервер должен быть доступен только в локальной сети. Инженеры OS X Server предложили разрешить удаленный доступ через VPN.
Урок 2: теперь есть новые параметры установки
Недавно я рассказал о своем опыте работы с Jenkins, и, к моему удивлению, нашел некоторые новые методы установки - Homebrew и даже Bitnami Mac App Storeверсия. Это, безусловно, стоит проверить. Джонатан Райт имеет подробный отчет о получении Homebrew Jenkins.
Урок 3: Нет, серьезно, не открывайте окно сборки в Интернете
Из исходного сообщения довольно ясно, что я не системный администратор и эксперт по безопасности. Здравый смысл в отношении личных вещей (брелоки, учетные данные, сертификаты и т.д.) Заставил меня чувствовать себя довольно неловко о том, чтобы положить ящик Jenkins в Интернет. Ник Арнотт в "Пренебреженном потенциале" очень легко подтвердил мои хеби-джеи в этой статьи.
TL; DR
Моя рекомендация другим лицам, пытающимся автоматизировать процесс их сборки, изменилась за последние полтора года. Убедитесь, что ваша машина Jenkins находится за вашим брандмауэром. Установите и установите Jenkins в качестве отдельного пользователя Jenkins либо с помощью установщика, версии Bitnami Mac App Store, Sami Tikka AppleScript и т.д.; это устраняет большую часть головной боли, о которой я подробно рассказывал выше. Если вам нужен удаленный доступ, настройка VPN-сервисов в OS X Server занимает десять минут. Я использую эту установку уже более года, и я очень доволен ею. Удачи!
