OS X 3.2.1 CI "ожидающая интеграции"

В течение последних нескольких дней я работал над тем, чтобы CI работал с внешним Mac OS OS X. Однако у меня было много проблем с OS X Server 3.2.1 и XCode 6.1b3.

Похоже, Apple исправила проблему в Xcode 6.1b3, которая не помещала правильные профили подготовки в Portal.keychain. Однако моя интеграция даже не работает.

После запуска чистой сборки OS X сервер XCode не будет интегрирован. Я успешно подключился к серверу и создал бота. Если я нахожусь на "SERVER.local" на моей машине разработки, я вижу бота, который я создал.

Все настроено правильно (в том числе сразу установите флажок для интеграции), однако моя интеграция находится в состоянии ожидания. Я проверил system.log, и ничего не происходит.

Это может быть совершенно не связанным, но каждый раз, когда я нажимаю на ожидающую интеграцию, я получаю эту ошибку в system.log:

NSFileCoordinator only handles URLs that use the file: scheme. This one does not:
x-code-xcsbot://XXX

Я не уверен, что это новая проблема, возникшая на OS X server 3.2.1, или если это просто проблема с настройкой. По-видимому, никто другой не имел этой проблемы, ничего не мог найти в Google/SO.

Ответ 1

Это происходит при запуске XCode бета-сборки в OS X Server.

Обратите внимание, что эта команда будет "удалять все ваши боты"
Запустите sudo xcrun xcscontrol --reset до reset.

https://devforums.apple.com/message/1051403#1051403

Ответ 2

Это все еще происходит, но если вы просто хотите подтолкнуть сервер к просыпаться и запускаться и не готовы удалять конфигурацию вашего x-code сервера (ProvisionProfiles, учетные данные и боты удаляются (как я помню)), просто запустите эту команду терминала

sudo -u _xcsbuildd /Applications/Xcode.app/Contents/Developer/usr/bin/xcsbuildd

Обратите внимание, что если у вас есть несколько оборотов Xcode в папке "Приложения", вы можете назвать их по-разному, поэтому команда может немного отличаться. В моем случае у меня есть файл с именем "Xcode 6.1.1". Таким образом, команда будет

sudo -u _xcsbuildd /Applications/Xcode\ 6.1.1.app/Contents/Developer/usr/bin/xcsbuildd

Ответ 3

Вот решение, которое может решить проблему, не требуя reset Xcode Server.

Какая проблема?

Сначала проверьте, применяется ли этот ответ, проверяя файл журнала xcsnginx.log:

sudo tail /Library/Developer/XcodeServer/Logs/xcsnginx.log

Найдите следующую строку в конце журнала:

nginx: [emerg] SSL_CTX_use_PrivateKey_file("/Library/Developer/XcodeServer/Certificates/xcsnginx.key") failed (SSL: error:0906A068:PEM routines:PEM_do_header:bad password read error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib)

Я не вижу эту запись в журнале, я боюсь, что этот ответ вам не поможет. Если вы видите эту запись, вы можете продолжить.

Почему это происходит?

Сервер Xcode внутренне запускает веб-сервер Nginx (на порту 20543) с именем xcsnginx, который действует как прокси-сервер между некоторыми службами. Этот сервер использует сертификат TLS/SSL для обеспечения безопасности сообщений. Привлеченные файлы следующие:

xcsnginx.crt: содержит сертификат PEM.
xcsnginx.key: содержит закрытый ключ для сертификата.
xcsnginx.pass: содержит ключевую фразу для закрытого ключа.

Насколько я понимаю, закрытый ключ хранится незашифрованным, что означает, что xcsnginx.pass должен быть пустым (и, кажется, reset при каждом запуске Xcode Server).

Однако по какой-то причине частный ключ в xcsnginx.key был экспортирован как зашифрованный ключ. Я понятия не имею, как и почему это может произойти, но это произошло на моем сервере, поэтому я предполагаю, что это может произойти и на вашем сервере. В результате xcsnginx не может загрузить сертификат и не запускаться.

Вы можете проверить, что xcsnginx не работает, выполнив:

pgrep xcsnginx || echo "Not running"

Как это исправить?

Вместо сброса Xcode Server с нуля мы можем:

снова экспортировать идентификатор из xcsnginx.keychain keychain или
восстановить предыдущий сертификат и клавишу или
создайте новый сертификат и ключ для xcsnginx.

Итак, давайте посмотрим на каждую опцию.

Вариант 1

Копии сертификата и закрытого ключа хранятся в цепочке xcsnginx.keychain, расположенной в /Library/Developer/XcodeServer/Keychains. Этот брелок защищен парольной фразой, хранящейся в файле с именем XCSNginxKeychainSharedSecret в папке /Library/Developer/XcodeServer/SharedSecrets.

Если вы знакомы с брелками OS X, вы можете получить сертификат и ключ из брелка.

Однако манипулирование цепочками ключей с использованием командной строки - настоящий кошмар, поэтому я дам это как упражнение для читателя (или редактора).

Вариант 2

Папка /Library/Developer/XcodeServer/Certificates может содержать резервную копию вашего сертификата и ключа. Пусть узнают:

sudo find /Library/Developer/XcodeServer/Certificates -name "*.original"

Если вам повезет, вы должны получить следующий результат:

/Library/Developer/XcodeServer/Certificates/xcsnginx.crt.original
/Library/Developer/XcodeServer/Certificates/xcsnginx.key.original
/Library/Developer/XcodeServer/Certificates/xcsnginx.pass.original

Это означает, что вы можете восстановить исходные файлы:

sudo cp /Library/Developer/XcodeServer/Certificates/xcsnginx.crt.original /Library/Developer/XcodeServer/Certificates/xcsnginx.crt
sudo cp /Library/Developer/XcodeServer/Certificates/xcsnginx.key.original /Library/Developer/XcodeServer/Certificates/xcsnginx.key
sudo cp /Library/Developer/XcodeServer/Certificates/xcsnginx.pass.original /Library/Developer/XcodeServer/Certificates/xcsnginx.pass

Вариант 3

Если вы не можете восстановить предыдущий сертификат и связки ключей, вы можете просто генерировать новые, например:

sudo openssl req -new -x509 -newkey rsa:2048 -nodes -out /Library/Developer/XcodeServer/Certificates/xcsnginx.crt -keyout /Library/Developer/XcodeServer/Certificates/xcsnginx.key -subj /CN=your-server.example.com -days 1000 -batch

где your-server.example.com заменяется DNS-адресом вашего сервера. В идеале сертификат должен выдаваться корневым центром сертификации Xcode Server, но использование однозадачного сертификата не представляет проблемы (насколько я сейчас/на данный момент/ваш пробег может отличаться).

Наконец

Теперь нам нужно подождать, пока система не запустит xcsnginx снова. Это должно произойти автоматически через минуту или меньше. Вы можете проверить, что xcsnginx начиналось с:

pgrep xcsnginx || echo "Not running"

Ответ 4

Вы можете использовать перезапуск вместо reset из командной строки для перезапуска сервера. Это приведет к завершению работы бота, который вы запустили.

sudo xcrun xcscontrol --restart

Ответ 5

Я сталкивался с этим несколько раз. Я сделал xcrun xcscontrol --reset, и он действительно работает, но я устал от этого. Поскольку мои боты усложняются с помощью триггеров предварительной и последующей интеграции, я не хочу их снова устанавливать.

То, что работало для меня на этот раз, просто переживало все недавние интеграции и deleting any canceled ones. Отмена запуска бота может оставить его в нечетном состоянии.

После того, как я удалил набор интеграций, я перезапустил машину, на которой работает сервер, и моя интеграция снова начинает работать!

Надеюсь, что это поможет кому-то.