builder

Build Management from Bell Labs Systems Technology Center

Feature Changes - Details
builder home page

Persistence of "Command_Line" settings
In earlier versions of builder, a "Command_Line" setting would get replaced during re-configuration by its run-time value. Not any more!

Viewpath node name change while maintaining node parameters
Since the Viewpath is the key to the parameters, earlier versions of builder would require you to re-input all the parameters if you changed the node name. Not any more!

More email formatting flexibility
General prettying-up of the email, and addition of new output content associated with new features (like hooks).

Usage Models and Templates
Builder now comes with several configuration templates to help get things started. It also comes with some documentation on how to use builder in specific models (IBEC mode, for example, or for distributed development).

NEXT! option during re-configuration
Builder now accepts "NEXT!" at any prompt during re-configuration. This tells builder to skip to the next viewpath node (i.e. that you are done making modifications to the current one).

Friendlier Status File names
Builder's status files now have more meaningful and understandable names.

Latest Build directory
Builder now maintains a "latest" directory (really a symbolic link). This directory always points to the most recent build. That way you can "cd" to the latest build directory without needing to know its name. This also makes it easier to make the status file directory accessible from the web.

"Continue without source changes" as a command line option
Builder now recognizes the "-C" option. For scenarios that are configured to be sensitive to it, this option will cause that particular instance to go ahead and execute the build even if there were no changes to source code.

Status files directory name indicates build success / failure
Builder modifies the status files directory name to indicate whether the build succeeded or failed, or had some system problem that precluded a build. This makes it easier to look for such things as "the most recent successful build", or "all of the build failures in the last month".

Support for "snapid" and "newsnapid" getversion options
Builder now supports the Sablime "snapid" option when extracting source, and the "newsnapid" option for saving the current extraction.

Operations Log for each build
Builder now maintains an Operations Log file during each build instance. This log records the date and time of each major sub-operation, and is handy for "tail -f" during a build.

Elimination of instance directories when only "update" or "display" is used.
When "builder -d" is used to display a scenario, or when "builder -f|F" is used to update one, builder now removes the status file directory that gets created. Thus, all your status directories will be ones where an actual build was intended.

Much less reliance on Sablime groups for data storage.
Builder used to use Sablime to store MR groups between builds, and for use during the current one. These groups tended to grow unwieldy and - I admit - builder did a poor job of maintenance. The current version has less reliance on Sablime groups, and does a better job of cleaning up after itself when it does use them.

Hooks to user code at critical points.
While earlier versions of builder had a few documented and a few more undocumented "hooks" out to user supplied code, builder v2 expands, documents, and normalizes this capability.

Support for multi-platform installations
Most of builder is KSH, and thus platform independent. Those parts of builder that are compiled, though, must execute on the same platform (i.e. architecture, e.g. sparc5, or HP). Some projects wish to have one builder installation on a shared file system to control builds on various platforms. Builder supports this by having an architecture bin within its normal bin. Only those components of builder that are platform specific need to be duplicated in the architecture bins. All other software and data can be shared.

Persistence of "Command_Line" settings	In earlier versions of builder, a "Command_Line" setting would get replaced during re-configuration by its run-time value. Not any more!
Viewpath node name change while maintaining node parameters	Since the Viewpath is the key to the parameters, earlier versions of builder would require you to re-input all the parameters if you changed the node name. Not any more!
More email formatting flexibility	General prettying-up of the email, and addition of new output content associated with new features (like hooks).
Usage Models and Templates	Builder now comes with several configuration templates to help get things started. It also comes with some documentation on how to use builder in specific models (IBEC mode, for example, or for distributed development).
NEXT! option during re-configuration	Builder now accepts "NEXT!" at any prompt during re-configuration. This tells builder to skip to the next viewpath node (i.e. that you are done making modifications to the current one).
Friendlier Status File names	Builder's status files now have more meaningful and understandable names.
Latest Build directory	Builder now maintains a "latest" directory (really a symbolic link). This directory always points to the most recent build. That way you can "cd" to the latest build directory without needing to know its name. This also makes it easier to make the status file directory accessible from the web.
"Continue without source changes" as a command line option	Builder now recognizes the "-C" option. For scenarios that are configured to be sensitive to it, this option will cause that particular instance to go ahead and execute the build even if there were no changes to source code.
Status files directory name indicates build success / failure	Builder modifies the status files directory name to indicate whether the build succeeded or failed, or had some system problem that precluded a build. This makes it easier to look for such things as "the most recent successful build", or "all of the build failures in the last month".
Support for "snapid" and "newsnapid" getversion options	Builder now supports the Sablime "snapid" option when extracting source, and the "newsnapid" option for saving the current extraction.
Operations Log for each build	Builder now maintains an Operations Log file during each build instance. This log records the date and time of each major sub-operation, and is handy for "tail -f" during a build.
Elimination of instance directories when only "update" or "display" is used.	When "builder -d" is used to display a scenario, or when "builder -f\|F" is used to update one, builder now removes the status file directory that gets created. Thus, all your status directories will be ones where an actual build was intended.
Much less reliance on Sablime groups for data storage.	Builder used to use Sablime to store MR groups between builds, and for use during the current one. These groups tended to grow unwieldy and - I admit - builder did a poor job of maintenance. The current version has less reliance on Sablime groups, and does a better job of cleaning up after itself when it does use them.
Hooks to user code at critical points.	While earlier versions of builder had a few documented and a few more undocumented "hooks" out to user supplied code, builder v2 expands, documents, and normalizes this capability.
Support for multi-platform installations	Most of builder is KSH, and thus platform independent. Those parts of builder that are compiled, though, must execute on the same platform (i.e. architecture, e.g. sparc5, or HP). Some projects wish to have one builder installation on a shared file system to control builds on various platforms. Builder supports this by having an architecture bin within its normal bin. Only those components of builder that are platform specific need to be duplicated in the architecture bins. All other software and data can be shared.