#sbt
#sbt
Вопрос:
У меня есть несколько модулей Scala, которые я создаю с помощью SBT. Некоторые из них (я буду называть их зависимыми модулями) публикуются в Artifactory, а затем используются модулями верхнего уровня.
Все изменения в коде выполняются в отдельных ветвях git. Когда функция (или исправление ошибки) завершена, эта ветвь компилируется в Jenkins, а затем развертывается в экземпляре тестирования и передается команде контроля качества.
Таким образом, возможно, что в зависимых модулях будет несколько ветвей git с разным кодом.
Проблема в том, что Ivy кэширует эти модули локально, поэтому возможно, что модуль верхнего уровня будет создан с зависимым модулем из другой ветви (взятым из локального кэша).
Я попытался добавить changing() директиву к спецификации зависимостей в build.sbt .
В этом случае Ivy игнорирует локальный кэш и каждый раз переходит в Artifactory для загрузки файла POM. Затем он анализирует файл POM, но приходит к выводу, что у него есть файл jar с этой версией в локальном кэше, и извлекает файл jar из локального кэша, а не из Artifactory. Это не то, что я хочу.
Поскольку код в ветвях на данный момент не был интегрирован в основную ветвь, совершенно справедливо, что разные ветви функций имеют одинаковый номер версии, но разный код.
Есть ли способ сообщить Ivy (через SBT) игнорировать локальный кэш для определенного groupid? Или хотя бы одну зависимость?
Комментарии:
1. Вы пробовали пометить версию как СНИМОК?
Ответ №1:
Если вы используете управление версиями для своих зависимых модулей, то каждое изменение кодовой базы должно создавать другую версию. Ivy и maven ожидают, что после публикации артефакта с определенной версией он останется неизменным навсегда. Вот почему они используют кэшированные файлы. Если вы хотите загружать новую версию из репозитория при каждой компиляции, вам следует добавить суффикс -SNAPSHOT к номеру версии зависимого модуля (например: dep-module-1.1.1-SNAPSHOT)
Комментарии:
1. Ну, добавление МОМЕНТАЛЬНОГО СНИМКА — это то же самое, что добавление изменения () к зависимости, как в
def appDependencies = Seq("com.foo"%"foo-api"%"1.0" changing(), .... Это заставляет Ivy извлекать файл POM из репозитория при каждой компиляции, но затем он не извлекает jar, как описано в исходном сообщении.2. Вы пробовали выполнять шаги по устранению неполадок, описанные в официальной документации SBT? scala-sbt.org/release/docs /…
3. Вы имеете в виду явно запущенное обновление? Нет, потому что я не уверен, что происходит с параллельными сборками в этом случае. Я решил свою непосредственную проблему, используя плагин sbt-dirty-money, который удаляет мой com. удалите артефакты из кэша ivy перед началом компиляции. Это работает отлично, потому что ivy приходится загружать артефакты каждый раз, поскольку они не будут в кэше. Однако я не уверен, что произойдет, если я использую параллельные сборки в Jenkins. В настоящее время я использую только одного исполнителя, так что этого не может произойти. И если я попытаюсь явно использовать update, я думаю, у меня возникнет та же проблема.
4. Насколько я могу судить, большинство ваших проблем связано с неправильным управлением версиями зависимых артефактов. Если ваши параллельные сборки запрашивают одну и ту же версию артефакта, но ожидают другого содержимого, это проблема. Вы могли бы принять некоторую автоматическую схему нумерации инкрементных версий. Это означает, что вам нужно синхронизировать содержимое build.sbt с последними версиями артефактов, но это делает параллельные сборки безопасными.
5. Они не имеют четкой версии, потому что они находятся в разных ветвях git (для разработки). И каждая ветвь — это свой собственный мир с особым управлением версиями внутри. Но без учета других ветвей. Это то, какими должны быть ветви разработки. Синхронизация номеров версий возможна, но за это приходится платить возможными человеческими ошибками, которых я бы очень хотел избежать.