2016-06-10 11 views
0

Я пытаюсь создать хранилище git, которое управляет моей средой. У меня есть набор lwrp, написанный для конкретных задач. Эти lwrps внутренне зависят от многих кулинарных книг сообщества.berks не разрешает зависимость от кулинарных книг

В каждой моей кулинарной книге есть файл Berksfile, где я указываю разрешение зависимости. В корневой папке моего репозитория у меня есть основной Berksfile, в котором перечислены все кулинарные книги, которые я хочу получить из моего репозитория.

Что я хочу сейчас, когда я делаю установку berks из корневого каталога, он должен извлекать мои кулинарные книги, а затем анализировать их, чтобы найти индивидуальный файл berks из каждой из этих кулинарных книг и разрешить все зависимости. Однако это не так.

У кого-нибудь есть идеи по этому вопросу? Это общий сценарий работы Berks? Или я что-то упускаю, так что зависимости не решены?

Чтобы дать больше информации: Моя поваренная книга имеет этот berksfile

source 'https://supermarket.chef.io' 
cookbook 'apache_spark', '~> 1.2.12' 

И апач искра имеет внутреннюю зависимость от

cookbook 'monit', github: 'phlipper/chef-monit', tag: '1.5.2' 
+0

Возможный дубликат [Решить рекурсивные зависимости поваренной книги в Git Berkshelf] (http://stackoverflow.com/questions/29603281/resolve-recursive-git-cookbook-dependencies-with-berkshelf) – StephenKing

+0

По крайней мере, я предполагаю, что он работает для кулинарных книг, которые не имеют рекурсивной зависимости, указывающей на Git repo ... – StephenKing

+0

Да, я предполагаю, что это своего рода дублирующий вопрос. И у нас нет решения, но я считаю, что для «рекурсивной зависимости, указывающей на Git repo». –

ответ

1

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

Как указано в других ответах, директивы Berksfile являются «непереходными». Зависимости в поваренной книге metadata.rb - это символические зависимости, просто имя и ограничение версии без информации о том, где его получить. Каждый инструмент, который работает с кулинарами, имеет другое представление о том, как обрабатывать эти символические зависимости, например, когда вы запускаете berks install, вы можете получать зависимости от супермаркета или GitHub, но когда клиент-клиент обрабатывает их, он получает все от Chef Server. Сохранение этого разделения между символическими зависимостями и тем, где их можно получить, позволяет многим инструментам сосуществовать. Berksfile содержит дополнительные данные о том, где можно загружать определенные кулинарные книги, добавляя или заменяя информацию из символических зависимостей, но поскольку эти дополнительные директивы не являются частью метаданных поваренной книги, они не могут быть выполнены рекурсивно.

Большая проблема заключается в том, что супермаркет представляет собой плоское пространство имен, поэтому может быть только одна кулинарная книга под названием monit. Это заставляет многих людей не публиковать вещи в Супермаркете и не зависит от них через директивы git source. Это означает, что depends "monit" уже не так ясно, как должно быть. Это действительно должно считаться ошибкой с неопубликованной кулинарной книгой, но я понимаю нежелание народов переименовывать свои кулинарные книги, чтобы их правильно выпускать.

Обычным решением является либо копирование макаронных изделий в ваш новый Berksfile из ваших восходящих потоков, либо создание изолированной юбки кулинарной книги в частном экземпляре супермаркета (или эквивалентной организации шеф-повара), где вы загружаете только то, что хотите , и при этом depends "monit" снова становится недвусмысленным.

+0

Да, прямо сейчас я имею дело с восходящим berksfile, в котором есть список всех поваренных книг, которые мне нужны, и указывает их на местоположение git с указанной веткой или тегом , –

+0

Я рекомендую не делать этого. Либо используйте конечную точку berkshelf/universe вашего сервера шеф-повара (доступную с 12,6 или около того), либо настройте собственный супермаркет. – StephenKing