Working With Packages

The Package resource identifies a few things about a specific package, such as the package name, the source name, user/group ownership, etc. It however does not specify the source vcs repository, or build handler, or what releases to build for. These are all set by separate package ‘branches’. Meaning, the Package resource acts as a parent object for the individual Package Branches to fall under.

Packages require project-admin privileges, meaning to create and modify packages the user must be a part of the project’s admin group.

Note: The below examples assume that you have set your ‘current-project’ to ‘my-project’, so as to not have to pass the ‘–project’ option with every command. This can be done as:

$ mf workon my-project

Creating a Package

$ mf package create \
    -l git17 \
    --summary "Fast Version Control System" \
    --source-name git \
    --user derks

Note: The significance of the –source-name option is that the builder systems will not build tasks simultaneously that have the same ‘source-name’. This can be an issue in some cases. Take MySQL for example... during the test process there is the potential that the test suite will use the same temporary listen port for both builds, which will clash. By setting the real name we can avoid any such clashes. So PHP and MySQL can build simultaneously but mysql50 and mysql51 .... or mysql51 and another task for mysql51 will not.

Updating a Package

$ mf package update git17 --group my-group --footprint 2

Note: Members of the package group have the same permission as the owner of the package. It can be looked at as, the owner or ‘user’ of the package is the primary owner, and members of the package’s group are secondary owners even though they both have the same permissions.

Note: The ‘footprint’ is an arbitrary number that can help even out builds on the workers. For example, a small package like ‘phpMyAdmin’ might take 1-2 minutes to build because it is noarch and small in size. This would be considered a footprint of ‘1’. On the other hand, something like MySQL might take 30-45 minutes to build because it is a large package and also has an exhaustive test suite to run. Something like that might be considered a footprint of ‘4’. The significance is that when MonkeyFarm looks for an available build system it takes the current load of the system and adds the footprint value to it... in hopes of guestimating what the total load will be once the new task is assigned. If the value is less than the ‘max_load’ for the build system... then it will be assigned.

Deleting a Package

$ mf package delete git17

Listing Packages

List all packages under ‘my-project’, that I own or whose group I belong to:

$ mf package listall
mysql50
php52
php53
git17

List all packages under ‘my-project’, that I own or whose group I belong to, but filter results:

$ mf package listall -f php
php52
php53

List all packages under ‘my-project’ that I own:

$ mf package listall --mine
git17

List all packages under ‘my-project’:

$ mf package listall --all
mysql50
mysql51
php52
php53
php54
python26
python31
git17

$ mf package listall --all -f python
python26
python31

Showing Data For a Package

$ mf package show git17

          Label | git17
        Summary | Fast Version Control System
    Source Name | git
          Owner | derks
        Project | my-project
    Group Owner | None
     Created On | 2011-01-27 09:40:21
    Last Update | 2011-01-27 09:40:21
      Auto ReUP | False
 One Per System | False
      Footprint | 1

       Branches | git17.rpm
                  git17.deb

Explanation of Options

Required Options:

-l/–label

The label of the package (how it is identified). This should always match the name of the package (i.e. the RPM %{name}).

—summary The summary of the package (less than 80 characters)

--source-name

The actual name of the source tarbal/upstream name. For example ‘apache’ (source name) vs. ‘httpd’ (Red Hat RPM name).

—user The user who affectively owns the package (primary maintainer).

Additional Options:

--group

A group that also has full permissions on the package.

—footprint An arbitrary number that helps MF calculate the expected load of a task on a builder. The default is 1, meaning that MF calculates the current load of a builder and adds 1. If that total is greater than ‘max_load’ of the builder then the task is not assigned to that builder. In generally this should not be used unless you really understand MonkeyFarm administration. For example, if your builder systems have a ‘max_load’ setting of 4, and you set the footprint of your package to ‘4’ then the task will never get assigned because the ‘current_load’ + ‘footprint’ will almost always be greater than 4. Use with caution.

--one-per-system

This option means that builders will only build one tasks at a time for any builds with the same ‘package.source_name’. This is useful for such packages as drizzle, or mysql that run temporary instances of their server daemon during the test suite. Running the tests from two builds at the same time would cause the temporary daemons to conflict with each other. Using the option ensures that only one ‘drizzle’ build will happen on a system at one time (for example).

—auto-reup This is currently not functional, but adds the ability for external applications to handle newer versions of releases. For example, you might have a package called ‘php’ and anytime there is a new release you want that package included (a new package-branch auto created for it). On the other hand, you might have a package called ‘php52’ that you only want available a specific release, but not newer releases. This is here for external applications to use.