#ios #caching #azure-devops #cocoapods #podfile-lock
#iOS #кэширование #azure-devops #cocoapods #podfile-блокировка
Вопрос:
Я получаю эту ошибку каждый раз, когда запускаю сборку через свой конвейер Azure devops:
Данный ключ кэша изменился в своем разрешенном значении между этапами восстановления и сохранения
Я пытаюсь кэшировать cocoapods, используемые в моем проекте react native. Я использую хэш подфайла.заблокируйте строку ключа кэша (если в подфайле есть изменения.заблокировать, тогда ключ кэша изменится, и новый кэш будет загружен после пропуска кэша)
локально, если я удалю Podfile.заблокируйте папку ios / Pods и затем запустите установку pod, ничего не изменится. Когда конвейер сборки запустится, установите Podfile.хэш блокировки меняется, что означает, что кэш никогда не может быть восстановлен, поскольку ключ всегда изменяется.
Я уже пробовал:
- изменение VMImage на 10.14 вместо macOS-последняя версия
- убедился, что локально все модули обновлены
- убедился, что версии cocoapods одинаковы локально и в конвейере сборки
Я не могу придумать, что еще попробовать, в документах Microsoft нет примеров кэширования cocoapods, и, похоже, никто не сталкивался с такой же проблемой
Ответ №1:
Вы можете попробовать следующий подход:
# Podfile.lock and project.pbxproj are changed during the build process, so we make copies
- script: |
cp ./ios/Podfile.lock ./ios/podfile_key
cp ./ios/AwesomeProject.xcodeproj/project.pbxproj ./ios/project_key
displayName: Create pod cache keys
- task: Cache@2
inputs:
key: 'pods | "$(Agent.OS)" | ./ios/podfile_key | ./ios/Podfile | ./ios/AwesomeProject.xcworkspace/contents.xcworkspacedata | ./ios/project_key'
path: './ios/Pods'
cacheHitVar: 'PODS_CACHE_RESTORED'
displayName: Cache pods
- task: CocoaPods@0
displayName: 'pod install using the CocoaPods task with defaults'
condition: ne(variables.PODS_CACHE_RESTORED, 'true')
inputs:
workingDirectory: './ios/'
forceRepoUpdate: false
Комментарии:
1. Спасибо aleksander_si спасибо за публикацию по этому вопросу. Одна вещь, которую я не понимаю, — это /podfile_key и /project_key . Откуда они берутся? когда вы создаете эти файлы?
2. Эти два файла создаются скриптом непосредственно перед задачей кэширования, см. Пример. В моем случае я хотел также аннулировать кеш, если изменяются файлы рабочей области и проекта, поэтому я добавил соответствующие файлы в подпись ключа кэша.
Ответ №2:
Ошибка указывает на то, что вам нужно убедиться, что ни один из ваших шагов сборки между этапом кэширования и этапом кэширования после задания не изменяет значение ключа кэша. Вы можете либо удалить шаг, вызывающий изменение, либо удалить Podfile.блокировка с помощью ключа.
Комментарии:
1. Не удалит Podfile. блокировка ключа полностью устраняет цель поиска / генерации кэша? Не вся идея в том, что ключ кэша генерируется из Podfile. заблокируйте хэш, и если Podfile. блокировка изменена (поскольку модули изменились), тогда следующий запуск приведет к потере кэша? Если вы просто укажете ключ, например, «foobar», разве это не всегда будет означать, что в кеш-блоках будет попадание в кеш (даже если они изменились)? Кроме того, странно то, что задачи кэширования npm работают безупречно, поэтому, похоже, что-то подозрительное конкретно с модулями.
2. Как выглядит ваш конвейер? Пожалуйста, проверьте этот блог, чтобы узнать, поможет ли он вам: medium.com/@zmoola22 /. …
3. @CeceDong-MSFT Я проследил за этим сообщением в блоге до конца и все еще сталкиваюсь с этой проблемой. По какой-то причине этап установки pod (необходимый и не может быть удален) вызывает изменение ключа кэша, что означает, что кэш не попадает при последующем запуске конвейера.
4. вы предлагаете удалить Podfile. блокировка из ключа кэша, есть ли какой-либо другой файл, который вы бы предложили включить вместо него? нам нужно включить хэш файла, который изменяется при изменении модулей проектов, что приведет к пропуску кэша (тогда хэш файла будет отличаться от сохраненного ключа кэша) и приведет к загрузке и сохранению нового кэша
5. К сожалению, я не вижу других файлов для кэширования.