Модифицируйте XCScheme и запишите его обратно на диск в сценарии post_install

Question

Я пишу post_install сценарий в моем Podfile чтобы можно было собирать отчеты о покрытии кода из моей среды, когда я запускаю модульные тесты в примере проекта. Вот что у меня есть:

post_install do |installer|
  pods_project = installer.pods_project
  shared_data_dir = Xcodeproj::XCScheme.shared_data_dir(pods_project.path)
  scheme_filename = "BonMot.xcscheme"
  scheme = Xcodeproj::XCScheme.new File.join(shared_data_dir, scheme_filename)
  test_action = scheme.test_action
  test_action.code_coverage_enabled = true
  scheme.test_action = test_action
  puts "now scheme is #{scheme}"
  scheme.save!
end

Когда я распечатываю схему, я могу убедиться, что сбор покрытия кода включен, и когда я проверяю дату изменения файла, он обновляется до текущего времени, хотя это легко объясняется тем фактом, что я запускаю pod install, Опция покрытия кода не записывается обратно в BonMot.xcscheme файл. Почему бы и нет?

Answer 1

Похоже post_install слишком рано работать со схемами. Установщик CocoaPods вызывает write_pod_project метод сразу после run_podfile_post_install_hooks на этапе "Создание стручков" и есть recreate_user_schemes позвони внутрь. Таким образом, ваша схема переписывается каждый раз в процессе установки.

Мне не очень нравится мое решение, но оно работает для меня:

post_install do |installer|

  orig_share_development_pod_schemes = installer.method :share_development_pod_schemes
  installer.define_singleton_method :share_development_pod_schemes do
    orig_share_development_pod_schemes.call

    # do what you want with schemes
  end

end

ОБНОВЛЕНИЕ (CocoaPods 1.2.0 и новее)

Поскольку решение основано на деталях реализации, оно вышло из строя после выпуска CocoaPods 1.2.0. Продолжая в том же направлении, я могу предложить новый метод переопределения:

post_install do |installer|

  orig_write_lockfiles = installer.method :write_lockfiles
  installer.define_singleton_method :write_lockfiles do
    # do what you want with schemes

    orig_write_lockfiles.call
  end

end

Answer 2

Вы используете installer.pods_project какой Pods.xcodeproj проект я верю.

Ваш BonMot.xcscheme Схема, вероятно, в вашем проекте приложения, а не в вашем проекте pods.

Итак, если это так, то ваш код делает то, что он, вероятно, создает совершенно новый Pods.xcodeproj/xcshareddata/xcschemes/BonMot.xcscheme файл, измените его запись покрытия кода и сохраните его вместо изменения существующего BonMotApp.xcodeproj/xcshareddata/xcschemes/BonMot.xcscheme схема.

Вы можете захотеть puts scheme.path а также puts pods_project.path отладить это и быть уверенным, что вы измените то, что ожидаете.

Вместо этого вы можете использовать ссылку на свой проект приложения:

app_project = aggregate_targets.map(&:user_project_path).uniq.first

Если вы действительно хотите изменить схему, включенную в Pods проект, эта схема, вероятно, не названа BonMot я полагаю, что это название вашего приложения, за исключением случаев, когда это имя фреймворка, внесенного в вашу рабочую область как Pod разработки через CocoaPods.

---

Полное объяснение:

Это потому, что даже если на практике я никогда не видел, чтобы это использовалось где-либо, CocoaPods позволяют интегрировать модули в несколько пользовательских проектов одновременно. Обычно у вас есть только один xcodeproj, но вы действительно можете указать xcodeproj прямо в вашем target … do блоки, чтобы указать конкретный проект Xcode, к которому принадлежит цель, и таким образом интегрировать ваши модули в цели различных проектов.

Так что эта строка будет спрашивать каждого стручка aggregate_target (цели pod, которые агрегируют pod для определенной цели приложения), к какому пользовательскому проекту он относится, и затем мы удаляем дубликаты в этом списке пользовательских проектов. Тогда, как на практике у нас (99,9% времени) обычно есть только один проект приложения, мы можем получить первую и единственную запись в этом списке.