Thanks Mike, I didn't know about the path option actually.Though In my case I would keep a Berksfile in each cookbook still, which is another way of doing it.On Tue, Apr 14, 2015 at 3:09 PM, Mike < " target="_blank"> > wrote:As to the "how does berks work with a monolithic repo with multiple cookbooks", here's a couple of lines from a Berksfile we use that points to a github repo that has a bunch of cookbooks in it, and are referenced by paths.# External cookbooks to <THIS> repocookbook 'dd-base', git: ' :DataDog/ourmonolithicrepo.git', branch: 'master', rel: 'site-cookbooks/dd-base'cookbook 'dd-consul', git: ' :DataDog/ourmonolithicrepo.git', branch: 'prod', rel: 'site-cookbooks/dd-consul'# cookbooks in <THIS> repo, relative to the Berksfilecookbook 'workspace', path: './site-cookbooks/workspace'Does this clutter up the local ~/.berkshelf/ cache directory with multiple copies of the same git repo? Maybe. But who cares? It works. :)It's pretty flexible - so as long as you figure out "when does my team need to create a new cookbook repo" vs "when does my team need to create a new cookbook in the existing repo" - that's a workflow problem, and berks will play nice either way.-MOn Tue, Apr 14, 2015 at 7:45 PM, Yoshi Spendiff < " target="_blank"> > wrote:Yeah that's the thought train I was heading down too, which is why I was wondering if anyone had any experience to the contrary. There's obvious benefits to having cookbooks as independent objects but that doesn't mean you need to follow the whole preachy philosophy.On Tue, Apr 14, 2015 at 11:27 AM, Lamont Granquist < " target="_blank"> > wrote:
I've never needed to point into a multiple-cookbook repo so not familiar with using the rel: option. I'd still argue that you shouldn't need to do that, but yeah that renders that question moot.
So, really it sounds like Berkshelf fully supports this method of arranging cookbooks. Period. Full Stop. You do not need to rearrange your cookbooks into single git repos to use Berkshelf.
The problem is that Berkshelf authors and users were noisy about the single git repo model being superior, and that's been conflated with the tool not being usable if you didn't drink all the kool aid.
On 4/14/15 11:15 AM, Yoshi Spendiff wrote:
I was more asking if you SHOULD rather than if you COULD. It's definitely possible.Isn't that only a problem if you have multiple repos with multiple cookbooks? If you've got one repo with all your role and wrapper cookbooks, and then peel off individual library cookbooks which are one-cookbook-per-repo then it should work okay and you can just use `path: ../some_cookbook` in the Berksfile for the internal dependencies of the monolithic repo, and avoid having the library cookbooks having deps back into your monolithic repo (which would smell like you're starting to create circular dependencies).I think this is a bit of a moot point isn't it? You CAN actually specify a git repository that has multiple cookbooks, using the rel: option. You just can't do this in a single Berksfile declaration, which is never going to be supported.
Berkshelf should work fine for this model as well.
On Tue, Apr 14, 2015 at 11:11 AM, Lamont Granquist < " target="_blank"> > wrote:
On 4/13/15 1:17 PM, Kevin Keane Subscription wrote:
Isn't that only a problem if you have multiple repos with multiple cookbooks? If you've got one repo with all your role and wrapper cookbooks, and then peel off individual library cookbooks which are one-cookbook-per-repo then it should work okay and you can just use `path: ../some_cookbook` in the Berksfile for the internal dependencies of the monolithic repo, and avoid having the library cookbooks having deps back into your monolithic repo (which would smell like you're starting to create circular dependencies).
The problem with berkshelf is that you can specify a git repository as source per cookbook, but you can't really specify a git repository that contains multiple cookbooks.
Berkshelf should work fine for this model as well.
--
--
--
Archive powered by MHonArc 2.6.16.