Working With Builds ------------------- 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: .. code-block:: text $ mf workon my-project Brief Summary of Build Types ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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. .. code-block:: text $ mf build list-types $ mf build create-type -l bug $ mf build update-type bug -l some_other_label $ mf build delete-type bug Creating a Build ^^^^^^^^^^^^^^^^ .. code-block:: text $ 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 -buildXX.* Updating a Build ^^^^^^^^^^^^^^^^ Builds can not be updated by regular users, and are generally only updated by the system throughout the build process. Deleting a Build ^^^^^^^^^^^^^^^^ .. code-block:: text $ mf build delete php-5.2.14-1 Closing a Build ^^^^^^^^^^^^^^^ .. code-block:: text $ 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: .. code-block:: text $ mf build open php-5.2.14-1 Listing Builds ^^^^^^^^^^^^^^ List all open builds for a project: .. code-block:: text $ 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: .. code-block:: text $ 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: .. code-block:: text $ 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 : Tagging and Untagging Builds ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. code-block:: text $ 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: .. code-block:: text $ mf build untag php-5.2.14-1 --tag testing --no-rebuild Adding and Removing Bugs to a Build ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. code-block:: text $ 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.* Show Data For a Build ^^^^^^^^^^^^^^^^^^^^^ .. code-block:: text $ 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 Getting All Data for a Build ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. code-block:: text $ 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.