Builds are submitted for a package, which triggers MonkeyFarm to create associated tasks for each target in the specified releases. For example, if the package ‘php’ has the releases ‘el5’, ‘el6’ assigned to it, then once a build is submitted for it the system will create tasks for ‘el5.i386’, ‘el5.x86_64’, ‘el6.i386’, etc... depending on the releases and targets that are configured. A build is essentially the parent object of the overall task to build the package against the required targets.
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
The build type determines why the build is being submitted. Some builds may address more than one type, however the highest priority should be used. For example if a build addresses a number of bugs, but also security fixes then the type should be set as ‘security’. Bug types can be added as well.
$ mf build list-types
$ mf build create-type -l bug
$ mf build update-type bug -l some_other_label
$ mf build delete-type bug
$ mf build create -l php-5.2.14-1 --package-branch php.fc14 --type bug
Note: It is obvious that nobody wants to specify the label of each build, which generally requires knowing the version of the source and what not. It is assumed that users will develop wrappers around the MonkeyFarm utility to make operations like this easier. Creating a script to pull package and version information from say the current-working-directory, and then submitting a build based on that info would be quite trivial. That said, if the -l/label is omitted one will be generated based on <package>-buildXX.
Builds can not be updated by regular users, and are generally only updated by the system throughout the build process.
$ mf build delete php-5.2.14-1
$ mf build close php-5.2.14-1
Note: This should only be done if a) the build needs to be saved, and b) you do not want to ‘tag’ it as anything. In the section regarding Working With Tags we see that we can create tags with the option of ‘close_on_tag’ meaning that builds will be closed when applying that tag. It is best practice to have a ‘stable’ tag that closes builds for you. That said, the only reason to not tag a build is if it is not successful (has failed tasks) or just not ready to be pushed to any of the tags. Otherwise it should be deleted or tagged.
You can also re-open a build:
$ mf build open php-5.2.14-1
List all open builds for a project:
$ mf build listall
# but filter results
$ mf build listall -f php
# include builds that are closed
$ mf build listall --all
# but filter the results
$ mf build listall --all -f php
List all open builds for a project, only the ones that I own:
$ mf build listall --mine
# including builds that are closed
$ mf build listall --mine --all
# and filter results
$ mf build listall --mine --all -f php
Builds also have a quick view option:
$ mf build quickview
php-5.2.14-1php-5.2.14-1 (BuildSuccess)
> php-5.2.14-1.el5.i386 : BuildSuccess : :
> php-5.2.14-1.el5.x86_64 : BuildProcessing : build00 :
$ mf build tag php-5.2.14-1 --tag testing-candidate
$ mf build untag php-5.2.14-1 --tag testing-candidate
Note: Tags are a means of organizing builds, and are explained more in the Working With Tags section.
There may also be situations where you don’t want to rebuild the tag repo data (like yum repo) when tagging or untagging a task:
$ mf build untag php-5.2.14-1 --tag testing --no-rebuild
$ mf build add-bug php-5.2.14-1 --bug XXXXXX
$ mf build remove-bug php-5.2.14-1 --bug YYYYYY
Note: Bugs are arbitrary identifiers. The URL which links to the bug is determined by the ‘bug_handler’ assigned to the project as outlined in the Working With Projects section.
$ mf build show php-5.2.14-1
Label | php-5.2.14-1
Owner | john.doe
Package | php-pecl-apc
Project Branch | php-pecl-apc.fc14
Project | my-project
Created On | 2010-12-01 10:10:09
Last Update | 2010-12-01 10:17:07
Start Time | 2010-12-01 10:10:20
End Time | 2010-12-01 10:17:07
Status | BuildSuccess
Scratch? | False
Scratch URL |
Data Dir | projects/rpmdev/builds/php-5.2.14-1
Build Type | newpackage
End of Life | False
Releases | el5
Tasks | php-5.2.14-1.el5.i386
php-5.2.14-1.el5.x86_64
Tags | testing-candidate
Bugs | https://bugs.launchpad.net/my-project/+bug/XXXXXX
https://bugs.launchpad.net/my-project/+bug/YYYYYY
$ mf build getarchive php-5.2.14-1
This downloads a tarbal of all the task data for the build, including files, configs, logs, and sources.