Нет, не должны. Потому что это не “user-generated content”. Файлы, которые всегда можно скачать ещё раз лучше хранить в подкаталоге Library, который не синхронизируется в iCloud, а если файл нужен только один раз сразу же после скачивания — в tmp.
Есть мнение, что слово «fun» нельзя просто так взять и перевести на русский как «весело».
Честно положа руку на орган — такой перевод — признак пофигизма.
Постарайтесь понять смысл и передать его вместо дословного, но идиотического «весело».
Прямо бесит уже.
fastlane не смотрели?
Попробуйте carthage вместо подов, если iOS 8+ — не поганит проект, добавляется одна фаза сборки, остальное из терминала примерно так же.
А вообще, могу порекомендовать уже готовых руби-скриптов для автоматизации сборок.
Раз у вас есть доверительная близость с админами, а сам агент полностью ваш — Fastlane вам в помощь.
Ещё раз вам повторяю — собирать руками не надо, настройте сборку библиотек на сборочном агенте, помечайте тэгом коммит из которого собрались артефакты, подтягивайте артефакты из этой сборки в сборку самого проекта — сборочный агент умеет это делать автоматически без ваших рук.
Все ваши требования удовлетворены, плюс — счастливый Боб, не ожидающий у корыта по 7 минут сборки зависимостей.
Я и предлагаю решение — сертификат для продавлена всего один, подписывать релизные сборки на сборочном сервере надо им, а не каким-то пашей или машей, так больше порядка, имхо.
Тут не в сарказме дело, ваш сценарий крайне оптимистичен, особенно, для вечера пятницы )
Посыл был в том, что не каждый программист — Боб, не все конторы разрешают лазить каким-то разработчикам по сборочным серверам и что-то там настраивать.
Предлагаете все зависимости собирать в отдельные бинарники и затем их подключать руками к проекту вместе с кучей хедер файлов?
Предлагаю собирать зависимости отдельно от проекта и хранить артефакты сборки для использования во время сборки проекта. Всё это автоматически без всяких рук умеет собирать TeamCity.
вместе с кучей хедер файлов?
Тому же TeamCity не важно сколько этих заголовочных файлов он распакует из артефакта-архива для сборки проекта.
Не желаете заголовочные файлы отдельно хранить — делайте статичный или динамический фреймворк и подключайте его — сложного мало.
Возможно, это кому-то удобно, я даже знаю ребят кто так делает, но мне удобнее когда всё динамически само разруливается.
Дело не только в удобстве, этот подход точно уменьшает время сборки и ваш Боб ждал бы не 6-7 минут — когда же соберутся сначала все зависимости, а меньше минуты, пока они скачаются и распакуются.
Но, конечно же, можно кататься на стульях, размахивая палками, пока компилируется — дело вкуса )
просит админов дать доступ до сервера, коннектится туда по ssh и начинает выяснять, в чем же, именно, проблема и как её можно решить.
Боб, похоже, ответственный и образованный программист, раз ему админы легко дают доступ на сборочный сервер по ssh.
Да и админы не успели убежать пораньше в пятницу-то — тоже ответственные товарищи, хорошо знающие Боба и доверяющие ему.
причем, сначала xcode компилирует зависимости (cocoapods) и уже только после проверяет валидность подписи, то есть только когда собирает основное приложение. Поэтому ошибка проявляется примерно во второй половине процесса сборки, из-за чего первые 6-7 минут потрачены в пустую, от чего Боб расстроен еще больше.
Боб был бы меньше расстроен, если бы предсобранные зависимости статически линковались (динамические — подкладывались) вместо их полной сборки. Собранные ранее бинарники зависимостей — артефакты сборки проектов зависимостей, собираются только при изменении в репозитории.
Простите, но зачем на сборочном сервере собирать продакшн-релиз и подписывать его сертификатом Developer'а?
Что мешает сделать сертификат для подписи продакшн-релизов, положить его только на сборочный сервер, изменить одну строчку в .xcconfig и забыть про эту ошибку хотя бы на год?
Нет, не должны. Потому что это не “user-generated content”. Файлы, которые всегда можно скачать ещё раз лучше хранить в подкаталоге Library, который не синхронизируется в iCloud, а если файл нужен только один раз сразу же после скачивания — в tmp.
Ах вот оно что
Получается, что Presenter знает про UIKit.
IP на третий, TCP на четвёртый.
Объясните, пожалуйста эту мысль.
Есть мнение, что слово «fun» нельзя просто так взять и перевести на русский как «весело».
Честно положа руку на орган — такой перевод — признак пофигизма.
Постарайтесь понять смысл и передать его вместо дословного, но идиотического «весело».
Прямо бесит уже.
Нет, не все.
Попробуйте carthage вместо подов, если iOS 8+ — не поганит проект, добавляется одна фаза сборки, остальное из терминала примерно так же.
Раз у вас есть доверительная близость с админами, а сам агент полностью ваш — Fastlane вам в помощь.
Все ваши требования удовлетворены, плюс — счастливый Боб, не ожидающий у корыта по 7 минут сборки зависимостей.
Посыл был в том, что не каждый программист — Боб, не все конторы разрешают лазить каким-то разработчикам по сборочным серверам и что-то там настраивать.
Предлагаю собирать зависимости отдельно от проекта и хранить артефакты сборки для использования во время сборки проекта. Всё это автоматически без всяких рук умеет собирать TeamCity.
Тому же TeamCity не важно сколько этих заголовочных файлов он распакует из артефакта-архива для сборки проекта.
Не желаете заголовочные файлы отдельно хранить — делайте статичный или динамический фреймворк и подключайте его — сложного мало.
Дело не только в удобстве, этот подход точно уменьшает время сборки и ваш Боб ждал бы не 6-7 минут — когда же соберутся сначала все зависимости, а меньше минуты, пока они скачаются и распакуются.
Но, конечно же, можно кататься на стульях, размахивая палками, пока компилируется — дело вкуса )
Боб, похоже, ответственный и образованный программист, раз ему админы легко дают доступ на сборочный сервер по ssh.
Да и админы не успели убежать пораньше в пятницу-то — тоже ответственные товарищи, хорошо знающие Боба и доверяющие ему.
Боб был бы меньше расстроен, если бы предсобранные зависимости статически линковались (динамические — подкладывались) вместо их полной сборки. Собранные ранее бинарники зависимостей — артефакты сборки проектов зависимостей, собираются только при изменении в репозитории.
Простите, но зачем на сборочном сервере собирать продакшн-релиз и подписывать его сертификатом Developer'а?
Что мешает сделать сертификат для подписи продакшн-релизов, положить его только на сборочный сервер, изменить одну строчку в .xcconfig и забыть про эту ошибку хотя бы на год?