[chef] Re: Re: Re: Re: Better workflow for actively-developed cookbooks

[Jamie Winsor < >]

Hey Wes / Bryan, et all

We (Riot Games) have a software solution for this very problem that we will be announcing to the community in the next few days. We've been using it internally and just want to get our messaging and documentation setup before we do so.

We have every single Cookbook in it's a separate Git repository of it's own and each one of those maps to a job on our build server. The job on the build server calls this software solution and it gathers dependencies of the Cookbook we're building and allows you to then publish it, and it's dependencies, to your Chef server.

Every single application project at Riot also uses this dependency getter to figure out what Cookbook Versions should be used to deploy the built artifact by either reading a Lockfile or coming up with a solution based on the metadata of the Cookbooks found in the dependency file and their dependencies.

With this tool we're able to iterate quickly and version our Cookbooks in a more sane manner. It allows you to throw out the idea that you should be keeping Cookbooks in your Chef-Repo.

I'll be sending an email to the list when we're ready.

-- 

Jamie Winsor

@resetexistence

https://github.com/reset

On Friday, June 22, 2012 at 2:28 PM, Bryan Berry wrote:

alright, I have a pretty heterodox idea of how I would like to use librarian-chef so that a team of infrastructure devs can work in sync

I am on a team of 3 infrastructure devs, i am the (relative) expert, the other 2 guys are smart but n00bs

I want us to have one common Cheffile in our one common chef-repo

the cookbooks we develop independently each have their own git repo, unfortunately, private ones for the most part

When I create a new git repository for application-foo, I want to add the git repository link, branch name/tag/commit name, to Cheffile so that when the other guys are working, they can easily pull in the cookbooks that I am working on and vice versa

However, I dont want to do the `git add . && git commit -am 'foo' && git push origin master && librarian-chef update`  dance when I am actively working on a cookbook that is within an "active" cookbook.

I don't need librarian to resolve any dependencies for my active cookbooks, I just want a common file w/ the list of all cookbooks we are working on as a team and i want librarian to download them if they don't exist already.

Perhaps this is a perversion of all things bundler but this is what I want. It also would get much more complicated if we didn't have git repos w/ shared commit access.

Is this crazy or a good idea or both?

On Fri, Jun 22, 2012 at 11:01 PM, Jay Feldblum < " target="_blank"> > wrote:

Wes,

It's a good question.

Right now, the reason is that the Knife integration is a little too simplistic for its ambitions.

The Knife integration does not manipulate the cookbook_path. Instead, you do that yourself. The Knife integration just tells you the path to use when set the cookbook_path.

There are certainly better ways out there to do it, ways which might address what you are asking about, and which I may explore in the future.

Cheers,
Jay

On Fri, Jun 22, 2012 at 1:24 PM, Wes Morgan < " target="_blank"> > wrote:

Thanks for your clarifications. I understand most of it, and I'm not actually asking for those things to be changed. I don't think. :)

What I really need, and what I should have said first:

With bundler, when I specify a :path => option, it just uses the code in that path directly. Is there a reason Librarian-Chef can't do that and instead copies it into the cookbooks dir? If there were just the one directory for the path'd cookbook, that would pretty much solve my problem. It sounded like the L-C knife integration could manipulate knife's cookbook path, so I was surprised it didn't do that and just point it at the directory specified in the :path => option.

Wes