Chef

Table Of Contents

git

A resource defines the desired state for a single configuration item present on a node that is under management by Chef. A resource collection—one (or more) individual resources—defines the desired state for the entire node. During every chef-client run, the current state of each resource is tested, after which the chef-client will take any steps that are necessary to repair the node and bring it back into the desired state.

Use the git resource to manage source control resources that exist in a git repository. git version 1.6.5 (or higher) is required to use all of the functionality in the git resource.

Note

This resource is often used in conjunction with the deploy resource.

Syntax

The syntax for using the git resource in a recipe is as follows:

git "name" do
  attribute "value" # see attributes section below
  ...
  action :action # see actions section below
end

where

  • git tells the chef-client to use the Chef::Provider::Git provider during the chef-client run.
  • "name" is the location in which the source files will be placed and/or synchronized with the files under source control management
  • attribute is zero (or more) of the attributes that are available for this resource
  • :action identifies which steps the chef-client will take to bring the node into the desired state

For example:

git "#{Chef::Config[:file_cache_path]}/app_name" do
  repository node[:app_name][:git_repository]
  revision node[:app_name][:git_revision]
  action :sync
  notifies :run, "bash[compile_app_name]"
end

where

  • the name of the resource is #{Chef::Config[:file_cache_path]}/libvpx
  • the repository and reference nodes tell the chef-client which repository and revision to use

Actions

This resource has the following actions:

Action Description
:sync Default. Use to update the source to the specified version, or to get a new clone or checkout.
:checkout Use to clone or check out the source. When a checkout is available, this provider does nothing.
:export Use to export the source, excluding or removing any version control artifacts.

Attributes

This resource has the following attributes:

Attribute Description
additional_remotes An array of additional remotes that are added to the git repository configuration.
checkout_branch Use to specify the name of a branch to be checked out. Default value: deploy.
depth The number of past revisions that will be included in the git shallow clone. The default behavior will do a full clone.
destination The path to the location to which the source will be cloned, checked out, or exported. Default value: the name of the resource block. (See “Syntax” section above for more information.)
enable_checkout Use to check out a repo from master. Default value: true.
enable_submodules Use to perform a sub-module initialization and update. Default value: false.
group The system group that is responsible for the checked-out code.
provider Optional. Use to explicitly specify a provider. (See “Providers” section below for more information.)
reference The alias for revision.
remote The remote repository to be used when synchronizing an existing clone.
repository The URI for the git repository.
revision The revision to be checked out. This can be symbolic, like HEAD or it can be a source control management-specific revision identifier. Default value: HEAD.
ssh_wrapper The path to the wrapper script used when running SSH with git. The GIT_SSH environment variable is set to this.
timeout The amount of time (in seconds) to wait for a command to execute before timing out. When this attribute is specified using the deploy resource, the value of the timeout attribute is passed from the deploy resource to the git resource.
user The system user that is responsible for the checked-out code.

Providers

Where a resource represents a piece of the system (and its desired state), a provider defines the steps that are needed to bring that piece of the system from its current state into the desired state.

The chef-client will determine the correct provider based on configuration data collected by Ohai at the start of the chef-client run. This configuration data is then mapped to a platform and an associated list of providers.

Generally, it’s best to let the chef-client choose the provider and this is (by far) the most common approach. However, in some cases specifying a provider may be desirable. There are two approaches:

  • Use a more specific short name—yum_package "foo" do instead of package "foo" do, script "foo" do instead of bash "foo" do, and so on—when available
  • Use the provider attribute to specify the long name as an attribute of a resource, e.g. provider Chef::Provider::Long::Name

This resource has the following providers:

Long name Short name Notes
Chef::Provider::Git git This provider works only with git.

Examples

The following examples demonstrate various approaches for using resources in recipes. If you want to see examples of how Chef uses resources in recipes, take a closer look at the cookbooks that Chef authors and maintains: https://github.com/opscode-cookbooks.

Use the git mirror

git "/opt/mysources/couch" do
  repository "git://git.apache.org/couchdb.git"
  revision "master"
  action :sync
end

Use different branches

To use different branches, depending on the environment of the node:

if node.chef_environment == "QA"
   branch_name = "staging"
else
   branch_name = "master"
end

git "/home/user/deployment" do
   repository "git@github.com:gitsite/deployment.git"
   revision branch_name
   action :sync
   user "user"
   group "test"
end

where the branch_name variable is set to staging or master, depending on the environment of the node. Once this is determined, the branch_name variable is used to set the revision for the repository. If the git status command is used after running the example above, it will return the branch name as deploy, as this is the default value. Run the chef-client in debug mode to verify that the correct branches are being checked out:

$ sudo chef-client -l debug

Install an application from git using bash

The following example shows how Bash can be used to install a plug-in for rbenv named ruby-build, which is located in git version source control. First, the application is synchronized, and then Bash changes its working directory to the location in which ruby-build is located, and then runs a command.

 git "#{Chef::Config[:file_cache_path]}/ruby-build" do
   repository "git://github.com/sstephenson/ruby-build.git"
   reference "master"
   action :sync
 end

 bash "install_ruby_build" do
   cwd "#{Chef::Config[:file_cache_path]}/ruby-build"
   user "rbenv"
   group "rbenv"
   code <<-EOH
     ./install.sh
     EOH
   environment 'PREFIX' => "/usr/local"
end

To read more about ruby-build, see here: https://github.com/sstephenson/ruby-build.

Upgrade packages from git

The following example shows the scm resource using the git short name as part of a larger recipe that is used to upgrade packages:

#  the following code sample comes from the ``source`` recipe in the ``libvpx-cookbook`` cookbook: https://github.com/enmasse-entertainment/libvpx-cookbook

git "#{Chef::Config[:file_cache_path]}/libvpx" do
  repository node[:libvpx][:git_repository]
  revision node[:libvpx][:git_revision]
  action :sync
  notifies :run, "bash[compile_libvpx]", :immediately
end