Build classes let you organize builds in even the most complex environments. You do not need to create a build class—by default, a simple organizational structure is set up for you. But, if you have diverse product lines, or multiple product releases, you should set up and use build classes. The Cluster Manager lets you perform build management tasks such as stopping or deleting builds and creating, editing, or deleting build classes.
Stopping Builds
You can stop an in-progress build by one of three methods:
-
Press Ctrl-C from the terminal where you invoked eMake
-
Use Accelerator’s web interface
-
Use
cmtool—Accelerator’s command-line tool
The Cluster Manager automatically terminates builds that seem to be hung. If the Cluster Manager does not receive a request from eMake for 60 seconds, it considers the build hung and the build is terminated.
Stopping a Single Build from the Web Interface
-
Click the Builds tab.
-
Click Stop Build in the Action column on the row exhibiting your build ID and Name.
Stopping Multiple Builds from the Web Interface
-
Click the Builds tab.
-
Go to the Filter drop-down menu and select the desired filter.
-
Click Run Filter.
-
Click Stop Filtered Builds.
-
From the Filter menu, select none, then click Run Filter.
Stopping a Build Using cmtool
| This is an advanced option for those who are familiar with using command-line tools. |
-
Request a list of running builds. The syntax is:
% cmtool --cm <clustermanager:port> getBuilds --filter <field name>=<value>For example, if linuxbuilder is the Cluster Manager host name, type:% cmtool --cm linuxbuilder getBuilds --filter "result =1"A list of running builds will display accompanied by a number of attributes for each build-for example: Build ID, machine name, build class, owner, build start time, and so on. The Build ID is used to identify a build for termination. Also, you can obtain additional information or include comments about the build. For example, to sort builds by start time and request only the first ten builds display, enter:% cmtool --cm linuxbuilder getBuilds --order Id --filter="ID<11"To get failed builds:% cmtool --cm linuxbuilder getBuilds --order "start_time desc" --filter "result >0" -
After you determine which build you need to terminate, use this syntax for ending a build:
% cmtool --cm <clustermanager> stopBuild <buildId>For example, to end build 4458, type:
% cmtool --cm linuxbuilder stopBuild 4458
Deleting Builds
Creating Build Classes
-
On the Build Classes page, click New Build Class.
This opens an empty build class details page.
-
Name the build class.
The build class name identifies the class to eMake for invoking a build.
You must assign the build’s class name through an eMake command-line option when the build is invoked: --emake-class=<exact build class name>. If no build class is assigned, the Cluster Manager assigns the build to the default class. If the class name typed on the eMake command line does not match a class name already in Cluster Manager, eMake exits.
-
Enter the build class tag definition.
To avoid errors, follow standard naming conventions for tag definitions by using numbers, letters, and underscores only without leading or trailing white space. Use a percent sign on either side of any variables used. (For example, %DATE%.) Use underscores ( _ ) instead of spaces.
-
Edit the remaining fields or keep their default values. See Create or Edit a Build Class for field definitions.
-
Click OK when all fields are completed.
When you return to the Build Classes page, you will see the new build class in the table.
Build Class Examples
Suppose your company has two major product lines: SuperSoftware and MegaSoftware. SuperSoftware runs on Windows and Solaris platforms. MegaSoftware runs on Windows only. You could begin by setting up three classes that include the product name, the platform, and the current version number for each product:
-
You could name the first class Supersoftware_Win_v.2.1. The tag definition for this class would be:
%BUILD_CLASS%_%LC%_%a%_%b%_%d%_%H%_%M%_%S%
The result would be a series of builds each named, or tagged , with the product name, the platform, the version number, a serial number (unique to the class), and the date for each build, for example:
Supersoftware_Win_v.2.1_12345_WED_AUG_22_14_37_12
-
You could name the second class Supersoftware_Sol_v.1.7. The tag definition can be the same as in our first example because it would be distinguished by the second build class name. Build tags in the second class would look like:
Supersoftware_Sol_v.1.7_12356_WED_AUG_23_11_14_39
-
You could name the third class MegaSoftware_Win_v.1.3. For this product, the tag definition would be similar to the previous examples, but also could include the name of the user who started the build because the MegaSoftware team is spread over several different locations. For this class, the tag definition might look like:
%BUILD_CLASS%%LC%%USER_NAME%_%DATE%
As in the first two examples, the result would be a sequentially numbered series of builds with the product name, platform, version number, name of the user who ran the build, and the date of each build assigned through the build class:
MegaSoftware_Win_v.1.3_12356_JSMITH_20050411100838
Additional classes could be created when the development of SuperSoftware or MegaSoftware entered a new phase, such as a new platform release or a new version release. In this way, the builds for each stage of development can be segmented into logical sets facilitating a more manageable and organized workflow.
Editing Build Classes
-
On the Build Classes page, click the Edit Build Class link in the Actions column.
or
On the Build Class Details page, click Edit Build Class.
This opens an Edit Build Class page with the fields populated with the information you used to create the build class.
-
Re-type or reselect the information you want to change.
See Build Classes - Create or Edit a Build Class for field definitions.
-
Click OK after you finish making changes.