Thursday, July 6, 2017

chef habitat plan syntax

pkg_name

Required. Sets the name of the package. This will be used along with pkg_origin, and pkg_version to define the fully-qualified package name, which determines where the package is installed to on disk, how it is referred to in package metadata, and so on. A pkg_name can contain upper and lowercase letters, numbers, dashes, and underscores. 

Example :  pkg_name=zlib


pkg_origin

Required unless overridden by the HAB_ORIGIN environment variable. The origin is used to denote a particular upstream of a package. A pkg_origin can contain upper and lowercase letters, numbers, dashes, and underscores. 

Example : pkg_origin=Habitat


pkg_shasum

Required if a valid URL is provided for pkg_source or unless do_verify() is overridden. The value for pkg_shasum is a sha-256 sum of the downloaded pkg_source. If you do not have the checksum, you can easily generate it by downloading the source and using the sha256sum or gsha256sum tools. Also, if you do not have do_verify() overridden, and you do not have the correct sha-256 sum, then the expected value will be shown in the build output of your package. 

pkg_shasum=36658cb768a54c1d4dec43c3116c27ed893e88b02ecfcb44f2166f9c0b7f2a0d

pkg_description

Required for core plans, optional otherwise. A short description of the package. It can be a simple string, or you can create a multi-line description using markdown to provide a rich description of your package. 

example :
  pkg_description=$(cat << EOF
  # My package description
  This is the package for the foo library. It's pretty awesome.
  EOF
  )


Optionals:
pkg_version
pkg_source
pkg_deps
pkg_lib_dirs
pkg_include_dirs
pkg_bin_dirs
pkg_pconfig_dirs
pkg_svc_run
pkg_exports
pkg_exposes
pkg_binds
pkg_binds_optional
pkg_interpreters
pkg_svc_user
pkg_svc_group
pkg_upstream_url
pkg_license
pkg_filename
pkg_build_deps


Variables:
The following variables can be used in your plans to help get binaries and libraries to build and install in the correct locations in your package.

$pkg_prefix

The absolute path for your package.

$CFLAGS
C compiler options.

$PREFIX
Where to install the software; same as $pkg_prefix

Callbacks 

When defining your plan, you have the flexibility to override the default behavior of Habitat in each part of the package building stage through a series of callbacks. To define a callback, simply create a shell function of the same name in your plan.sh file and then write your script. If you do not want to use the default callback behavior, you must override the callback and return 0 in the function definition.

These callbacks are listed in the order that they are called by the package build script.

do_build()
The default implementation is to update the prefix path for the configure script to use $pkg_prefix and then run make to compile the downloaded source. This means the script in the default implementation does ./configure --prefix=$pkg_prefix && make. You should override this behavior if you have additional configuration changes to make or other software to build and install as part of building your package.

do_check()
The default implementation runs nothing during post-compile. An example of a command you might use in this callback is make test. To use this callback, two conditions must be true. A) do_check() function has been declared, B) DO_CHECK environment variable exists and set to true, env DO_CHECK=true.

do_install()
The default implementation is to run make install on the source files and place the compiled binaries or libraries in HAB_CACHE_SRC_PATH/$pkg_dirname, which resolves to a path like /hab/cache/src/packagename-version/. It uses this location because of do_build() using the --prefix option when calling the configure script. You should override this behavior if you need to perform custom installation steps, such as copying files from HAB_CACHE_SRC_PATH to specific directories in your package, or installing pre-built binaries into your package.

Hooks
Each plan can have a hooks subdirectory that specifies any of the hooks or asynchronous callbacks described in this section. Each hook is a script with a shebang defined at the top to specify the interpreter to be used.

References : 

No comments:

Post a Comment