Announcing Berkshelf - Manage your Cookbooks like your gems


#1

Chefs,

We (Riot Games) have been hard at work these last few months setting up a continuous delivery process for not only our software, but also for the cookbooks that configure our software. Today we open sourced the first of a line of tools which we will be rolling out to the community.

Berkshelf is a way to manage a cookbook or an application’s cookbook dependencies. It allows you to treat cookbooks like you treat gems. At Riot we are using Berkshelf on every internal application. A Berksfile is included in each application with a strict version lock to ensure we only deploy our build artifacts with the proper accompanying cookbook version. Given an application “league” it is accompanied by a Berksfile containing the line:

cookbook “league”, git: "git@github.riotgames.com:riot/league.git", branch: “~> 1.61.0”

This ensures that during each build we always deploy the latest and greatest patches of the cookbook we deem appropriate for deploying the built artifact.

Berkshelf is also good for setting up a continuous delivery process for your Cookbooks themselves, too. At Riot every cookbook is stored in it’s own Git repository which contains a Berksfile containing the line:

metadata

This marks the current working directory as being a cookbook itself for Berkshelf to take actions upon. These jobs will unit test, lint test, validate syntax, and then upload the cookbook to our Chef Server for consumption by other applications.

We hope that you find Berkshelf as useful as we do.

http://www.berkshelf.com.
https://github.com/riotgames/berkshelf

Pull requests welcome!


Jamie Winsor
@resetexistence


#2

DNS fail on my part.

You’ll want to hit http://berkshelf.com until the CNAME for www is working properly.

Sorry for the confusion!


Jamie Winsor
@resetexistence

On Monday, June 25, 2012 at 12:39 PM, Jamie Winsor wrote:

Chefs,

We (Riot Games) have been hard at work these last few months setting up a continuous delivery process for not only our software, but also for the cookbooks that configure our software. Today we open sourced the first of a line of tools which we will be rolling out to the community.

Berkshelf is a way to manage a cookbook or an application’s cookbook dependencies. It allows you to treat cookbooks like you treat gems. At Riot we are using Berkshelf on every internal application. A Berksfile is included in each application with a strict version lock to ensure we only deploy our build artifacts with the proper accompanying cookbook version. Given an application “league” it is accompanied by a Berksfile containing the line:

cookbook “league”, git: "git@github.riotgames.com (mailto:git@github.riotgames.com):riot/league.git", branch: “~> 1.61.0”

This ensures that during each build we always deploy the latest and greatest patches of the cookbook we deem appropriate for deploying the built artifact.

Berkshelf is also good for setting up a continuous delivery process for your Cookbooks themselves, too. At Riot every cookbook is stored in it’s own Git repository which contains a Berksfile containing the line:

metadata

This marks the current working directory as being a cookbook itself for Berkshelf to take actions upon. These jobs will unit test, lint test, validate syntax, and then upload the cookbook to our Chef Server for consumption by other applications.

We hope that you find Berkshelf as useful as we do.

http://www.berkshelf.com.
https://github.com/riotgames/berkshelf

Pull requests welcome!


Jamie Winsor
@resetexistence
https://github.com/reset


#3

Hey Jamie,

Awesome work!

How does berkshelf compare to librarian-chef?

afaict, it uses a different mechanism to store and link to them, this gets
around the issue of when you want to edit a cookbook managed by librarian,
you can’t really do that w/out using :path and then librarian-chef install && librarian-chef update You’ve also got groups which looks like a very
neat feature

What else is different?

On Mon, Jun 25, 2012 at 11:42 PM, Jamie Winsor jamie@vialstudios.comwrote:

DNS fail on my part.

You’ll want to hit http://berkshelf.com until the CNAME for www is
working properly.

Sorry for the confusion!


Jamie Winsor
@resetexistence
https://github.com/reset

On Monday, June 25, 2012 at 12:39 PM, Jamie Winsor wrote:

Chefs,

We (Riot Games) have been hard at work these last few months setting up a
continuous delivery process for not only our software, but also for the
cookbooks that configure our software. Today we open sourced the first of a
line of tools which we will be rolling out to the community.

Berkshelf is a way to manage a cookbook or an application’s cookbook
dependencies. It allows you to treat cookbooks like you treat gems. At Riot
we are using Berkshelf on every internal application. A Berksfile is
included in each application with a strict version lock to ensure we only
deploy our build artifacts with the proper accompanying cookbook version.
Given an application “league” it is accompanied by a Berksfile containing
the line:

cookbook “league”, git: "git@github.riotgames.com:riot/league.git",
branch: “~> 1.61.0”

This ensures that during each build we always deploy the latest and
greatest patches of the cookbook we deem appropriate for deploying the
built artifact.

Berkshelf is also good for setting up a continuous delivery process for
your Cookbooks themselves, too. At Riot every cookbook is stored in it’s
own Git repository which contains a Berksfile containing the line:

metadata

This marks the current working directory as being a cookbook itself for
Berkshelf to take actions upon. These jobs will unit test, lint test,
validate syntax, and then upload the cookbook to our Chef Server for
consumption by other applications.

We hope that you find Berkshelf as useful as we do.

http://www.berkshelf.com.
https://github.com/riotgames/berkshelf

Pull requests welcome!


Jamie Winsor
@resetexistence
https://github.com/reset


#4

You pretty much hit the key difference there - centralized storage.

We set out to create a tool which would allow us to develop our cookbooks rapidly and make them first class citizens on a build server. The first task was pretty easy since @mitchellh (Vagrant) did all of that work for us.

The second goal was a bit tougher; we had to integrate with a build process for two different types of jobs.

One job is a cookbook job and the other is an application. In the case of a cookbook build job your CI server listens for changes in version control and then goes to work. We added the ‘metadata’ keyword which allows Berkshelf to resolve the current working project’s dependencies much like Bundler’s ‘gemspec’ function.

The other job is an application who has an ‘application cookbook’. In this case every application contains a Berksfile which contains only one source entry pointing to the application’s cookbook.

We have some additional things coming which will make Berkshelf more of a Bundler / RubyGems hybrid, but until then this is the basis of what we needed to accomplish to unblock our continuous delivery pipeline.

We’ll be improving portability and adding Windows support in the next release by dropping Gecode. You can expect some big fixes along the way and additional features to follow after we finish up a pure Ruby constraint solver in 0.4.0.


Jamie Winsor
@resetexistence

On Tuesday, June 26, 2012 at 2:08 AM, Bryan Berry wrote:

Hey Jamie,

Awesome work!

How does berkshelf compare to librarian-chef?

afaict, it uses a different mechanism to store and link to them, this gets around the issue of when you want to edit a cookbook managed by librarian, you can’t really do that w/out using :path and then librarian-chef install && librarian-chef update You’ve also got groups which looks like a very neat feature

What else is different?

On Mon, Jun 25, 2012 at 11:42 PM, Jamie Winsor <jamie@vialstudios.com (mailto:jamie@vialstudios.com)> wrote:

DNS fail on my part.

You’ll want to hit http://berkshelf.com until the CNAME for www is working properly.

Sorry for the confusion!


Jamie Winsor
@resetexistence
https://github.com/reset

On Monday, June 25, 2012 at 12:39 PM, Jamie Winsor wrote:

Chefs,

We (Riot Games) have been hard at work these last few months setting up a continuous delivery process for not only our software, but also for the cookbooks that configure our software. Today we open sourced the first of a line of tools which we will be rolling out to the community.

Berkshelf is a way to manage a cookbook or an application’s cookbook dependencies. It allows you to treat cookbooks like you treat gems. At Riot we are using Berkshelf on every internal application. A Berksfile is included in each application with a strict version lock to ensure we only deploy our build artifacts with the proper accompanying cookbook version. Given an application “league” it is accompanied by a Berksfile containing the line:

cookbook “league”, git: "git@github.riotgames.com (mailto:git@github.riotgames.com):riot/league.git", branch: “~> 1.61.0”

This ensures that during each build we always deploy the latest and greatest patches of the cookbook we deem appropriate for deploying the built artifact.

Berkshelf is also good for setting up a continuous delivery process for your Cookbooks themselves, too. At Riot every cookbook is stored in it’s own Git repository which contains a Berksfile containing the line:

metadata

This marks the current working directory as being a cookbook itself for Berkshelf to take actions upon. These jobs will unit test, lint test, validate syntax, and then upload the cookbook to our Chef Server for consumption by other applications.

We hope that you find Berkshelf as useful as we do.

http://www.berkshelf.com.
https://github.com/riotgames/berkshelf

Pull requests welcome!


Jamie Winsor
@resetexistence
https://github.com/reset


#5

The pure ruby constraint solver could be beneficial toward Chef
itself, I’m sure there is no other reason to be tied to libgecode –
it has to be packaged by Opscode for Ubuntu, even… although the
omnibus packages make most of those problems minimal

–AJ

On 26 June 2012 21:23, Jamie Winsor jamie@vialstudios.com wrote:

You pretty much hit the key difference there - centralized storage.

We set out to create a tool which would allow us to develop our cookbooks
rapidly and make them first class citizens on a build server. The first task
was pretty easy since @mitchellh (Vagrant) did all of that work for us.

The second goal was a bit tougher; we had to integrate with a build process
for two different types of jobs.

One job is a cookbook job and the other is an application. In the case of a
cookbook build job your CI server listens for changes in version control and
then goes to work. We added the ‘metadata’ keyword which allows Berkshelf to
resolve the current working project’s dependencies much like Bundler’s
’gemspec’ function.

The other job is an application who has an ‘application cookbook’. In this
case every application contains a Berksfile which contains only one source
entry pointing to the application’s cookbook.

We have some additional things coming which will make Berkshelf more of a
Bundler / RubyGems hybrid, but until then this is the basis of what we
needed to accomplish to unblock our continuous delivery pipeline.

We’ll be improving portability and adding Windows support in the next
release by dropping Gecode. You can expect some big fixes along the way and
additional features to follow after we finish up a pure Ruby constraint
solver in 0.4.0.


Jamie Winsor
@resetexistence
https://github.com/reset

On Tuesday, June 26, 2012 at 2:08 AM, Bryan Berry wrote:

Hey Jamie,

Awesome work!

How does berkshelf compare to librarian-chef?

afaict, it uses a different mechanism to store and link to them, this gets
around the issue of when you want to edit a cookbook managed by librarian,
you can’t really do that w/out using :path and then librarian-chef install && librarian-chef update You’ve also got groups which looks like a very
neat feature

What else is different?

On Mon, Jun 25, 2012 at 11:42 PM, Jamie Winsor jamie@vialstudios.com
wrote:

DNS fail on my part.

You’ll want to hit http://berkshelf.com until the CNAME for www is working
properly.

Sorry for the confusion!


Jamie Winsor
@resetexistence
https://github.com/reset

On Monday, June 25, 2012 at 12:39 PM, Jamie Winsor wrote:

Chefs,

We (Riot Games) have been hard at work these last few months setting up a
continuous delivery process for not only our software, but also for the
cookbooks that configure our software. Today we open sourced the first of a
line of tools which we will be rolling out to the community.

Berkshelf is a way to manage a cookbook or an application’s cookbook
dependencies. It allows you to treat cookbooks like you treat gems. At Riot
we are using Berkshelf on every internal application. A Berksfile is
included in each application with a strict version lock to ensure we only
deploy our build artifacts with the proper accompanying cookbook version.
Given an application “league” it is accompanied by a Berksfile containing
the line:

cookbook “league”, git: "git@github.riotgames.com:riot/league.git", branch:
"~> 1.61.0"

This ensures that during each build we always deploy the latest and greatest
patches of the cookbook we deem appropriate for deploying the built
artifact.

Berkshelf is also good for setting up a continuous delivery process for your
Cookbooks themselves, too. At Riot every cookbook is stored in it’s own Git
repository which contains a Berksfile containing the line:

metadata

This marks the current working directory as being a cookbook itself for
Berkshelf to take actions upon. These jobs will unit test, lint test,
validate syntax, and then upload the cookbook to our Chef Server for
consumption by other applications.

We hope that you find Berkshelf as useful as we do.

http://www.berkshelf.com.
https://github.com/riotgames/berkshelf

Pull requests welcome!


Jamie Winsor
@resetexistence
https://github.com/reset


#6

The pure Ruby constraint solver will be shipped as a separate Gem and included into Berkshelf as a dependency.

Provided it’s fast enough, we could for sure swap the Chef gecode dependency for it.


Jamie Winsor
@resetexistence

On Tuesday, June 26, 2012 at 2:45 AM, AJ Christensen wrote:

The pure ruby constraint solver could be beneficial toward Chef
itself, I’m sure there is no other reason to be tied to libgecode –
it has to be packaged by Opscode for Ubuntu, even… although the
omnibus packages make most of those problems minimal

–AJ

On 26 June 2012 21:23, Jamie Winsor <jamie@vialstudios.com (mailto:jamie@vialstudios.com)> wrote:

You pretty much hit the key difference there - centralized storage.

We set out to create a tool which would allow us to develop our cookbooks
rapidly and make them first class citizens on a build server. The first task
was pretty easy since @mitchellh (Vagrant) did all of that work for us.

The second goal was a bit tougher; we had to integrate with a build process
for two different types of jobs.

One job is a cookbook job and the other is an application. In the case of a
cookbook build job your CI server listens for changes in version control and
then goes to work. We added the ‘metadata’ keyword which allows Berkshelf to
resolve the current working project’s dependencies much like Bundler’s
’gemspec’ function.

The other job is an application who has an ‘application cookbook’. In this
case every application contains a Berksfile which contains only one source
entry pointing to the application’s cookbook.

We have some additional things coming which will make Berkshelf more of a
Bundler / RubyGems hybrid, but until then this is the basis of what we
needed to accomplish to unblock our continuous delivery pipeline.

We’ll be improving portability and adding Windows support in the next
release by dropping Gecode. You can expect some big fixes along the way and
additional features to follow after we finish up a pure Ruby constraint
solver in 0.4.0.


Jamie Winsor
@resetexistence
https://github.com/reset

On Tuesday, June 26, 2012 at 2:08 AM, Bryan Berry wrote:

Hey Jamie,

Awesome work!

How does berkshelf compare to librarian-chef?

afaict, it uses a different mechanism to store and link to them, this gets
around the issue of when you want to edit a cookbook managed by librarian,
you can’t really do that w/out using :path and then librarian-chef install && librarian-chef update You’ve also got groups which looks like a very
neat feature

What else is different?

On Mon, Jun 25, 2012 at 11:42 PM, Jamie Winsor <jamie@vialstudios.com (mailto:jamie@vialstudios.com)>
wrote:

DNS fail on my part.

You’ll want to hit http://berkshelf.com until the CNAME for www is working
properly.

Sorry for the confusion!


Jamie Winsor
@resetexistence
https://github.com/reset

On Monday, June 25, 2012 at 12:39 PM, Jamie Winsor wrote:

Chefs,

We (Riot Games) have been hard at work these last few months setting up a
continuous delivery process for not only our software, but also for the
cookbooks that configure our software. Today we open sourced the first of a
line of tools which we will be rolling out to the community.

Berkshelf is a way to manage a cookbook or an application’s cookbook
dependencies. It allows you to treat cookbooks like you treat gems. At Riot
we are using Berkshelf on every internal application. A Berksfile is
included in each application with a strict version lock to ensure we only
deploy our build artifacts with the proper accompanying cookbook version.
Given an application “league” it is accompanied by a Berksfile containing
the line:

cookbook “league”, git: "git@github.riotgames.com (mailto:git@github.riotgames.com):riot/league.git", branch:
"~> 1.61.0"

This ensures that during each build we always deploy the latest and greatest
patches of the cookbook we deem appropriate for deploying the built
artifact.

Berkshelf is also good for setting up a continuous delivery process for your
Cookbooks themselves, too. At Riot every cookbook is stored in it’s own Git
repository which contains a Berksfile containing the line:

metadata

This marks the current working directory as being a cookbook itself for
Berkshelf to take actions upon. These jobs will unit test, lint test,
validate syntax, and then upload the cookbook to our Chef Server for
consumption by other applications.

We hope that you find Berkshelf as useful as we do.

http://www.berkshelf.com.
https://github.com/riotgames/berkshelf

Pull requests welcome!


Jamie Winsor
@resetexistence
https://github.com/reset


#7

very cool!

I am still quite a ruby n00b. What is the purpose of the thor integration?

On Tue, Jun 26, 2012 at 11:23 AM, Jamie Winsor jamie@vialstudios.comwrote:

You pretty much hit the key difference there - centralized storage.

We set out to create a tool which would allow us to develop our cookbooks
rapidly and make them first class citizens on a build server. The first
task was pretty easy since @mitchellh (Vagrant) did all of that work for
us.

The second goal was a bit tougher; we had to integrate with a build
process for two different types of jobs.

One job is a cookbook job and the other is an application. In the case of
a cookbook build job your CI server listens for changes in version control
and then goes to work. We added the ‘metadata’ keyword which allows
Berkshelf to resolve the current working project’s dependencies much like
Bundler’s ‘gemspec’ function.

The other job is an application who has an ‘application cookbook’. In this
case every application contains a Berksfile which contains only one source
entry pointing to the application’s cookbook.

We have some additional things coming which will make Berkshelf more of a
Bundler / RubyGems hybrid, but until then this is the basis of what we
needed to accomplish to unblock our continuous delivery pipeline.

We’ll be improving portability and adding Windows support in the next
release by dropping Gecode. You can expect some big fixes along the way and
additional features to follow after we finish up a pure Ruby constraint
solver in 0.4.0.


Jamie Winsor
@resetexistence
https://github.com/reset

On Tuesday, June 26, 2012 at 2:08 AM, Bryan Berry wrote:

Hey Jamie,

Awesome work!

How does berkshelf compare to librarian-chef?

afaict, it uses a different mechanism to store and link to them, this gets
around the issue of when you want to edit a cookbook managed by librarian,
you can’t really do that w/out using :path and then librarian-chef install && librarian-chef update You’ve also got groups which looks like a very
neat feature

What else is different?

On Mon, Jun 25, 2012 at 11:42 PM, Jamie Winsor jamie@vialstudios.comwrote:

DNS fail on my part.

You’ll want to hit http://berkshelf.com until the CNAME for www is
working properly.

Sorry for the confusion!


Jamie Winsor
@resetexistence
https://github.com/reset

On Monday, June 25, 2012 at 12:39 PM, Jamie Winsor wrote:

Chefs,

We (Riot Games) have been hard at work these last few months setting up a
continuous delivery process for not only our software, but also for the
cookbooks that configure our software. Today we open sourced the first of a
line of tools which we will be rolling out to the community.

Berkshelf is a way to manage a cookbook or an application’s cookbook
dependencies. It allows you to treat cookbooks like you treat gems. At Riot
we are using Berkshelf on every internal application. A Berksfile is
included in each application with a strict version lock to ensure we only
deploy our build artifacts with the proper accompanying cookbook version.
Given an application “league” it is accompanied by a Berksfile containing
the line:

cookbook “league”, git: "git@github.riotgames.com:riot/league.git",
branch: “~> 1.61.0”

This ensures that during each build we always deploy the latest and
greatest patches of the cookbook we deem appropriate for deploying the
built artifact.

Berkshelf is also good for setting up a continuous delivery process for
your Cookbooks themselves, too. At Riot every cookbook is stored in it’s
own Git repository which contains a Berksfile containing the line:

metadata

This marks the current working directory as being a cookbook itself for
Berkshelf to take actions upon. These jobs will unit test, lint test,
validate syntax, and then upload the cookbook to our Chef Server for
consumption by other applications.

We hope that you find Berkshelf as useful as we do.

http://www.berkshelf.com.
https://github.com/riotgames/berkshelf

Pull requests welcome!


Jamie Winsor
@resetexistence
https://github.com/reset


#8

Thor is a lot like Rake - they are both task management tools like Make or Ant. These tools are great for building, testing, and releasing your software.

The Thor integration is useful if on your build server you use Thorfiles to automate your build process. It enables you to require our integration tasks into your own Thorfile and then invoke the tasks as if they were your own. This is nice because you don’t leave the current executing process. It’s just a clean way of doing things.

For example:

let’s say you are using Ant on your build server. You shell out to Berkshelf to install it’s dependencies. You then need to check the exit code from that shell out to know if you should continue executing.

If we were using Thor instead of Ant you could put this line at the top of your file:

require ‘berkshelf/thor’

And then within one of your task definitions you could put a line like this to install the dependencies:

invoke(“berkshelf:install”)

If the install fails it will exit the entire process with a helpful message and exit code that we have defined.

Thor is an amazing piece of software. It allows us to create a CLI application and tasks like these without writing any additional code.


Jamie Winsor
@resetexistence

On Tuesday, June 26, 2012 at 3:12 AM, Bryan Berry wrote:

very cool!

I am still quite a ruby n00b. What is the purpose of the thor integration?

On Tue, Jun 26, 2012 at 11:23 AM, Jamie Winsor <jamie@vialstudios.com (mailto:jamie@vialstudios.com)> wrote:

You pretty much hit the key difference there - centralized storage.

We set out to create a tool which would allow us to develop our cookbooks rapidly and make them first class citizens on a build server. The first task was pretty easy since @mitchellh (Vagrant) did all of that work for us.

The second goal was a bit tougher; we had to integrate with a build process for two different types of jobs.

One job is a cookbook job and the other is an application. In the case of a cookbook build job your CI server listens for changes in version control and then goes to work. We added the ‘metadata’ keyword which allows Berkshelf to resolve the current working project’s dependencies much like Bundler’s ‘gemspec’ function.

The other job is an application who has an ‘application cookbook’. In this case every application contains a Berksfile which contains only one source entry pointing to the application’s cookbook.

We have some additional things coming which will make Berkshelf more of a Bundler / RubyGems hybrid, but until then this is the basis of what we needed to accomplish to unblock our continuous delivery pipeline.

We’ll be improving portability and adding Windows support in the next release by dropping Gecode. You can expect some big fixes along the way and additional features to follow after we finish up a pure Ruby constraint solver in 0.4.0.


Jamie Winsor
@resetexistence
https://github.com/reset

On Tuesday, June 26, 2012 at 2:08 AM, Bryan Berry wrote:

Hey Jamie,

Awesome work!

How does berkshelf compare to librarian-chef?

afaict, it uses a different mechanism to store and link to them, this gets around the issue of when you want to edit a cookbook managed by librarian, you can’t really do that w/out using :path and then librarian-chef install && librarian-chef update You’ve also got groups which looks like a very neat feature

What else is different?

On Mon, Jun 25, 2012 at 11:42 PM, Jamie Winsor <jamie@vialstudios.com (mailto:jamie@vialstudios.com)> wrote:

DNS fail on my part.

You’ll want to hit http://berkshelf.com until the CNAME for www is working properly.

Sorry for the confusion!


Jamie Winsor
@resetexistence
https://github.com/reset

On Monday, June 25, 2012 at 12:39 PM, Jamie Winsor wrote:

Chefs,

We (Riot Games) have been hard at work these last few months setting up a continuous delivery process for not only our software, but also for the cookbooks that configure our software. Today we open sourced the first of a line of tools which we will be rolling out to the community.

Berkshelf is a way to manage a cookbook or an application’s cookbook dependencies. It allows you to treat cookbooks like you treat gems. At Riot we are using Berkshelf on every internal application. A Berksfile is included in each application with a strict version lock to ensure we only deploy our build artifacts with the proper accompanying cookbook version. Given an application “league” it is accompanied by a Berksfile containing the line:

cookbook “league”, git: "git@github.riotgames.com (mailto:git@github.riotgames.com):riot/league.git", branch: “~> 1.61.0”

This ensures that during each build we always deploy the latest and greatest patches of the cookbook we deem appropriate for deploying the built artifact.

Berkshelf is also good for setting up a continuous delivery process for your Cookbooks themselves, too. At Riot every cookbook is stored in it’s own Git repository which contains a Berksfile containing the line:

metadata

This marks the current working directory as being a cookbook itself for Berkshelf to take actions upon. These jobs will unit test, lint test, validate syntax, and then upload the cookbook to our Chef Server for consumption by other applications.

We hope that you find Berkshelf as useful as we do.

http://www.berkshelf.com.
https://github.com/riotgames/berkshelf

Pull requests welcome!


Jamie Winsor
@resetexistence
https://github.com/reset


#9

Tks for that great explanation

I will definitely have to take a look at thor
On Jun 26, 2012 12:20 PM, “Jamie Winsor” jamie@vialstudios.com wrote:

Thor is a lot like Rake - they are both task management tools like Make
or Ant. These tools are great for building, testing, and releasing your
software.

The Thor integration is useful if on your build server you use Thorfiles
to automate your build process. It enables you to require our integration
tasks into your own Thorfile and then invoke the tasks as if they were your
own. This is nice because you don’t leave the current executing process.
It’s just a clean way of doing things.

For example:

let’s say you are using Ant on your build server. You shell out to
Berkshelf to install it’s dependencies. You then need to check the exit
code from that shell out to know if you should continue executing.

If we were using Thor instead of Ant you could put this line at the top of
your file:

require ‘berkshelf/thor’

And then within one of your task definitions you could put a line like
this to install the dependencies:

invoke(“berkshelf:install”)

If the install fails it will exit the entire process with a helpful
message and exit code that we have defined.

Thor is an amazing piece of software. It allows us to create a CLI
application and tasks like these without writing any additional code.


Jamie Winsor
@resetexistence
https://github.com/reset

On Tuesday, June 26, 2012 at 3:12 AM, Bryan Berry wrote:

very cool!

I am still quite a ruby n00b. What is the purpose of the thor integration?

On Tue, Jun 26, 2012 at 11:23 AM, Jamie Winsor jamie@vialstudios.comwrote:

You pretty much hit the key difference there - centralized storage.

We set out to create a tool which would allow us to develop our cookbooks
rapidly and make them first class citizens on a build server. The first
task was pretty easy since @mitchellh (Vagrant) did all of that work for
us.

The second goal was a bit tougher; we had to integrate with a build
process for two different types of jobs.

One job is a cookbook job and the other is an application. In the case of
a cookbook build job your CI server listens for changes in version control
and then goes to work. We added the ‘metadata’ keyword which allows
Berkshelf to resolve the current working project’s dependencies much like
Bundler’s ‘gemspec’ function.

The other job is an application who has an ‘application cookbook’. In this
case every application contains a Berksfile which contains only one source
entry pointing to the application’s cookbook.

We have some additional things coming which will make Berkshelf more of a
Bundler / RubyGems hybrid, but until then this is the basis of what we
needed to accomplish to unblock our continuous delivery pipeline.

We’ll be improving portability and adding Windows support in the next
release by dropping Gecode. You can expect some big fixes along the way and
additional features to follow after we finish up a pure Ruby constraint
solver in 0.4.0.


Jamie Winsor
@resetexistence
https://github.com/reset

On Tuesday, June 26, 2012 at 2:08 AM, Bryan Berry wrote:

Hey Jamie,

Awesome work!

How does berkshelf compare to librarian-chef?

afaict, it uses a different mechanism to store and link to them, this gets
around the issue of when you want to edit a cookbook managed by librarian,
you can’t really do that w/out using :path and then librarian-chef install && librarian-chef update You’ve also got groups which looks like a very
neat feature

What else is different?

On Mon, Jun 25, 2012 at 11:42 PM, Jamie Winsor jamie@vialstudios.comwrote:

DNS fail on my part.

You’ll want to hit http://berkshelf.com until the CNAME for www is
working properly.

Sorry for the confusion!


Jamie Winsor
@resetexistence
https://github.com/reset

On Monday, June 25, 2012 at 12:39 PM, Jamie Winsor wrote:

Chefs,

We (Riot Games) have been hard at work these last few months setting up a
continuous delivery process for not only our software, but also for the
cookbooks that configure our software. Today we open sourced the first of a
line of tools which we will be rolling out to the community.

Berkshelf is a way to manage a cookbook or an application’s cookbook
dependencies. It allows you to treat cookbooks like you treat gems. At Riot
we are using Berkshelf on every internal application. A Berksfile is
included in each application with a strict version lock to ensure we only
deploy our build artifacts with the proper accompanying cookbook version.
Given an application “league” it is accompanied by a Berksfile containing
the line:

cookbook “league”, git: "git@github.riotgames.com:riot/league.git",
branch: “~> 1.61.0”

This ensures that during each build we always deploy the latest and
greatest patches of the cookbook we deem appropriate for deploying the
built artifact.

Berkshelf is also good for setting up a continuous delivery process for
your Cookbooks themselves, too. At Riot every cookbook is stored in it’s
own Git repository which contains a Berksfile containing the line:

metadata

This marks the current working directory as being a cookbook itself for
Berkshelf to take actions upon. These jobs will unit test, lint test,
validate syntax, and then upload the cookbook to our Chef Server for
consumption by other applications.

We hope that you find Berkshelf as useful as we do.

http://www.berkshelf.com.
https://github.com/riotgames/berkshelf

Pull requests welcome!


Jamie Winsor
@resetexistence
https://github.com/reset


#10

Nice work! I especially appreciate the effort you are making to explain
both this new tool as well as your general strategies for using chef and
continuous deployment.

Thanks,
Jeremiah

On Mon, Jun 25, 2012 at 3:39 PM, Jamie Winsor jamie@vialstudios.com wrote:

Chefs,

We (Riot Games) have been hard at work these last few months setting up a
continuous delivery process for not only our software, but also for the
cookbooks that configure our software. Today we open sourced the first of a
line of tools which we will be rolling out to the community.

Berkshelf is a way to manage a cookbook or an application’s cookbook
dependencies. It allows you to treat cookbooks like you treat gems. At Riot
we are using Berkshelf on every internal application. A Berksfile is
included in each application with a strict version lock to ensure we only
deploy our build artifacts with the proper accompanying cookbook version.
Given an application “league” it is accompanied by a Berksfile containing
the line:

cookbook “league”, git: "git@github.riotgames.com:riot/league.git",
branch: “~> 1.61.0”

This ensures that during each build we always deploy the latest and
greatest patches of the cookbook we deem appropriate for deploying the
built artifact.

Berkshelf is also good for setting up a continuous delivery process for
your Cookbooks themselves, too. At Riot every cookbook is stored in it’s
own Git repository which contains a Berksfile containing the line:

metadata

This marks the current working directory as being a cookbook itself for
Berkshelf to take actions upon. These jobs will unit test, lint test,
validate syntax, and then upload the cookbook to our Chef Server for
consumption by other applications.

We hope that you find Berkshelf as useful as we do.

http://www.berkshelf.com.
https://github.com/riotgames/berkshelf

Pull requests welcome!


Jamie Winsor
@resetexistence
https://github.com/reset


#11

This is super awesome.

Adam

On Mon, Jun 25, 2012 at 12:39 PM, Jamie Winsor jamie@vialstudios.com wrote:

Chefs,

We (Riot Games) have been hard at work these last few months setting up a
continuous delivery process for not only our software, but also for the
cookbooks that configure our software. Today we open sourced the first of a
line of tools which we will be rolling out to the community.

Berkshelf is a way to manage a cookbook or an application’s cookbook
dependencies. It allows you to treat cookbooks like you treat gems. At Riot
we are using Berkshelf on every internal application. A Berksfile is
included in each application with a strict version lock to ensure we only
deploy our build artifacts with the proper accompanying cookbook version.
Given an application “league” it is accompanied by a Berksfile containing
the line:

cookbook “league”, git: "git@github.riotgames.com:riot/league.git", branch:
"~> 1.61.0"

This ensures that during each build we always deploy the latest and greatest
patches of the cookbook we deem appropriate for deploying the built
artifact.

Berkshelf is also good for setting up a continuous delivery process for your
Cookbooks themselves, too. At Riot every cookbook is stored in it’s own Git
repository which contains a Berksfile containing the line:

metadata

This marks the current working directory as being a cookbook itself for
Berkshelf to take actions upon. These jobs will unit test, lint test,
validate syntax, and then upload the cookbook to our Chef Server for
consumption by other applications.

We hope that you find Berkshelf as useful as we do.

http://www.berkshelf.com.
https://github.com/riotgames/berkshelf

Pull requests welcome!


Jamie Winsor
@resetexistence
https://github.com/reset


Opscode, Inc.
Adam Jacob, Chief Customer Officer
T: (206) 619-7151 E: adam@opscode.com


#12

Hey Jamie,

metadata is awesome – single source of truth, yay! :slight_smile:

Windoze support would be super as well.

Cheers,
Torben
Am 26.06.2012 11:24 schrieb “Jamie Winsor” jamie@vialstudios.com:

You pretty much hit the key difference there - centralized storage.

We set out to create a tool which would allow us to develop our cookbooks
rapidly and make them first class citizens on a build server. The first
task was pretty easy since @mitchellh (Vagrant) did all of that work for
us.

The second goal was a bit tougher; we had to integrate with a build
process for two different types of jobs.

One job is a cookbook job and the other is an application. In the case of
a cookbook build job your CI server listens for changes in version control
and then goes to work. We added the ‘metadata’ keyword which allows
Berkshelf to resolve the current working project’s dependencies much like
Bundler’s ‘gemspec’ function.

The other job is an application who has an ‘application cookbook’. In this
case every application contains a Berksfile which contains only one source
entry pointing to the application’s cookbook.

We have some additional things coming which will make Berkshelf more of a
Bundler / RubyGems hybrid, but until then this is the basis of what we
needed to accomplish to unblock our continuous delivery pipeline.

We’ll be improving portability and adding Windows support in the next
release by dropping Gecode. You can expect some big fixes along the way and
additional features to follow after we finish up a pure Ruby constraint
solver in 0.4.0.


Jamie Winsor
@resetexistence
https://github.com/reset

On Tuesday, June 26, 2012 at 2:08 AM, Bryan Berry wrote:

Hey Jamie,

Awesome work!

How does berkshelf compare to librarian-chef?

afaict, it uses a different mechanism to store and link to them, this gets
around the issue of when you want to edit a cookbook managed by librarian,
you can’t really do that w/out using :path and then librarian-chef install && librarian-chef update You’ve also got groups which looks like a very
neat feature

What else is different?

On Mon, Jun 25, 2012 at 11:42 PM, Jamie Winsor jamie@vialstudios.comwrote:

DNS fail on my part.

You’ll want to hit http://berkshelf.com until the CNAME for www is
working properly.

Sorry for the confusion!


Jamie Winsor
@resetexistence
https://github.com/reset

On Monday, June 25, 2012 at 12:39 PM, Jamie Winsor wrote:

Chefs,

We (Riot Games) have been hard at work these last few months setting up a
continuous delivery process for not only our software, but also for the
cookbooks that configure our software. Today we open sourced the first of a
line of tools which we will be rolling out to the community.

Berkshelf is a way to manage a cookbook or an application’s cookbook
dependencies. It allows you to treat cookbooks like you treat gems. At Riot
we are using Berkshelf on every internal application. A Berksfile is
included in each application with a strict version lock to ensure we only
deploy our build artifacts with the proper accompanying cookbook version.
Given an application “league” it is accompanied by a Berksfile containing
the line:

cookbook “league”, git: "git@github.riotgames.com:riot/league.git",
branch: “~> 1.61.0”

This ensures that during each build we always deploy the latest and
greatest patches of the cookbook we deem appropriate for deploying the
built artifact.

Berkshelf is also good for setting up a continuous delivery process for
your Cookbooks themselves, too. At Riot every cookbook is stored in it’s
own Git repository which contains a Berksfile containing the line:

metadata

This marks the current working directory as being a cookbook itself for
Berkshelf to take actions upon. These jobs will unit test, lint test,
validate syntax, and then upload the cookbook to our Chef Server for
consumption by other applications.

We hope that you find Berkshelf as useful as we do.

http://www.berkshelf.com.
https://github.com/riotgames/berkshelf

Pull requests welcome!


Jamie Winsor
@resetexistence
https://github.com/reset


#13

On Tue, Jun 26, 2012 at 11:23 AM, Jamie Winsor jamie@vialstudios.comwrote:

You pretty much hit the key difference there - centralized storage.

We’ll be improving portability and adding Windows support in the next
release by dropping Gecode. You can expect some big fixes along the way and
additional features to follow after we finish up a pure Ruby constraint
solver in 0.4.0.

I couldn’t wait and have tried to get berkshelf installed on a windows box
(Ruby 1.9.3 + devkit), but no luck:

D:\chef>gem install berkshelf
Temporarily enhancing PATH to include DevKit…
Building native extensions. This could take a while…
ERROR: Error installing berkshelf:
ERROR: Failed to build gem native extension.

    W:/tools/vagrant/vagrant/vagrant/embedded/bin/ruby.exe extconf.rb

checking for main() in -lgecodesearch… no

Gecode >3.5 must be installed (http://www.gecode.org/).

I guess that’s exactly what you meant above. Probably I could get gecode
installed in the devkit mingw, but haven’t had the time to try further.

Just an idea: instead of writing a pure ruby constraint solver, wouldn’t it
be an option to use the gecoder gem which is supposed to work
cross-platform: http://gecoder.rubyforge.org/installation.html

(just installed it using gem install gecoder-with-gecode --platform=mswin32 but that didn’t help for berkshelf)

Cheers,
Torben


Jamie Winsor
@resetexistence
https://github.com/reset


#14

Hey Torben,

We’re very aware of the difficulties while installing Berkshelf on Windows. It is because of the Gecode requirement and it is not as easily solved as using the gecoder-with-gecode gem.

While Gecode does work on Windows, none of the Ruby gecode gems are still kept up-to-date except for DepSelector. Like Chef, we are using DepSelector, but it unfortunately does not work on Windows.


Jamie Winsor
@resetexistence

On Wednesday, June 27, 2012 at 9:48 AM, Torben Knerr wrote:

On Tue, Jun 26, 2012 at 11:23 AM, Jamie Winsor <jamie@vialstudios.com (mailto:jamie@vialstudios.com)> wrote:

You pretty much hit the key difference there - centralized storage.

We’ll be improving portability and adding Windows support in the next release by dropping Gecode. You can expect some big fixes along the way and additional features to follow after we finish up a pure Ruby constraint solver in 0.4.0.

I couldn’t wait and have tried to get berkshelf installed on a windows box (Ruby 1.9.3 + devkit), but no luck:

D:\chef>gem install berkshelf
Temporarily enhancing PATH to include DevKit…
Building native extensions. This could take a while…
ERROR: Error installing berkshelf:
ERROR: Failed to build gem native extension.

    W:/tools/vagrant/vagrant/vagrant/embedded/bin/ruby.exe extconf.rb

checking for main() in -lgecodesearch… no

Gecode >3.5 must be installed (http://www.gecode.org/).

I guess that’s exactly what you meant above. Probably I could get gecode installed in the devkit mingw, but haven’t had the time to try further.

Just an idea: instead of writing a pure ruby constraint solver, wouldn’t it be an option to use the gecoder gem which is supposed to work cross-platform: http://gecoder.rubyforge.org/installation.html

(just installed it using gem install gecoder-with-gecode --platform=mswin32 but that didn’t help for berkshelf)

Cheers,
Torben


Jamie Winsor
@resetexistence
https://github.com/reset


#15

Hi Jamie,

thanks for the explanation. Happily awaiting the 0.4.0 release now :slight_smile:

Regards,
Torben

On Wed, Jun 27, 2012 at 8:25 PM, Jamie Winsor jamie@vialstudios.com wrote:

Hey Torben,

We’re very aware of the difficulties while installing Berkshelf on
Windows. It is because of the Gecode requirement and it is not as easily
solved as using the gecoder-with-gecode gem.

While Gecode does work on Windows, none of the Ruby gecode gems are still
kept up-to-date except for DepSelector. Like Chef, we are using
DepSelector, but it unfortunately does not work on Windows.


Jamie Winsor
@resetexistence
https://github.com/reset

On Wednesday, June 27, 2012 at 9:48 AM, Torben Knerr wrote:

On Tue, Jun 26, 2012 at 11:23 AM, Jamie Winsor jamie@vialstudios.comwrote:

You pretty much hit the key difference there - centralized storage.

We’ll be improving portability and adding Windows support in the next
release by dropping Gecode. You can expect some big fixes along the way and
additional features to follow after we finish up a pure Ruby constraint
solver in 0.4.0.

I couldn’t wait and have tried to get berkshelf installed on a windows box
(Ruby 1.9.3 + devkit), but no luck:

D:\chef>gem install berkshelf
Temporarily enhancing PATH to include DevKit…
Building native extensions. This could take a while…
ERROR: Error installing berkshelf:
ERROR: Failed to build gem native extension.

    W:/tools/vagrant/vagrant/vagrant/embedded/bin/ruby.exe extconf.rb

checking for main() in -lgecodesearch… no

=========================================================================================
Gecode >3.5 must be installed (http://www.gecode.org/).

I guess that’s exactly what you meant above. Probably I could get gecode
installed in the devkit mingw, but haven’t had the time to try further.

Just an idea: instead of writing a pure ruby constraint solver, wouldn’t
it be an option to use the gecoder gem which is supposed to work
cross-platform: http://gecoder.rubyforge.org/installation.html

(just installed it using gem install gecoder-with-gecode --platform=mswin32 but that didn’t help for berkshelf)

Cheers,
Torben


Jamie Winsor
@resetexistence
https://github.com/reset