Automated Build Support
Automated Build Support (ABS) streamlines your workflow by automating builds of regular and XD (Server Workbench) runtimes through a scriptable interface. The interface allows you to specify everything you need for packaging including what Features and configuration maps are required to complete the process, as well as what packaging instructions should be used.
The specifications for packaging a runtime image can be stored in a VAST startup config file (abt.cnf) so that the build process is executed just by starting up a development image that has ABS pre-loaded. They can also be stored in the ENVY library and retrieved during the build process .
For automating regular runtime builds, you will need to load the ST: Automated Build Support feature, and for XD (Server Workbench) runtime builds, load the ST: Automated Build Support, XD feature. For more details on XD runtime builds, see “Automated XD Building” in the Server Guide.
The features include sample code to guide you in understanding the automated packaging process to your VAST application. See the class methods in the examples category the of AbsBuildSpecification and AbsXDBuildSpecification classes.
AbsBuildSpecification
The AbsBuildSpecification class provides support for normal runtime image packaging. It is a way to reliably test packaging and to create runtime images using a "clean" image. Note that it does not create packaging instructions, but instead requires packaging instructions that already work.
Note:
AbsBuildSpecification is used to build normal packages. For XD packaging see the class AbsXDBuildSpecification in AutomatedPackagingSupportXDApp.
The steps to automatically package are as follows:
2. Create a build specification (an instance of AbsBuildSpecification) which defines the prerequisite code (features, config maps, etc.), the defines the prerequisite code (features, config maps, etc.) code, and the config map containing the packaging instructions to use, and the name of the class defining the packaging instructions.
3. Ask the build specification to build the runtime image.
4. The results of the packaging process are placed in a subdirectory under the <
baseTargetDirectory>, commonly the current working directory. For more details see, “
Build Artifacts Output”.
Public Attributes available for defining an AbsBuildSpecification:
baseTargetDirectory: <CfsPath>
Overrides the default output folder used for storing all files generated during the packaging process.
The default value is a String which represents a CfsPath defining a directory tree under the current working directory with a root folder named <AbsBuildSpecfication name>, and a subfolder of the root folder with a name based on the current date and time. For example ‘Hello World\20220428173810’
featureNames: <OrderedCollection of String | Symbol>
The names of Features which are required by the Application being packaged. This an OrderedCollection of Feature common names (String) and/or Feature class names (Symbol).
leaveFilesInSourceDirectoryFlag: <Boolean>
Do not delete the files generated during the packaging process from the working directory. (Files are still copied to the target directory.)
logFileName: <String>
Set the path and name of the log file to which to write packaging progress and results messages.
The default name is <PackagingInstructionsClassName>.log.
mapNameContainingPackagingInstructions: <String> version: <String | nil>
Specify the configuration map name that contains the packaging instructions class. If a specific version is desired, specify the version name/number string; otherwise, nil means to use the latest version.
mapNamesContainingAppsToPackage: <OrderedCollection of String> version: <String | Nil>
Specify the list of config map names that contain the applications require for packaging. If a specific version is desired, specify the version name/number (all maps must have the same version name/number); otherwise, nil means to use the latest available edition/version.
name: <String>
Specify the unique name of the Automated Build Specification. This name is used as part of the key when saving the specification in the manager as well as for part of the baseTargetDirectory name.
packagingInstructionsClassName: <String>
Specify the class name that contains the packaging instructions to use for the build.
Public Actions:
build
After all attributes have been set, this action kicks off the packaging process.
delete
Delete the receiver from the ENVY library objects list of saved Automated Build Specifications.
save
Save the receiver in the ENVY library objects list of saved Automated Build Specifications for future use.
Validations and Logging
As part of the building process the attributes of the build specification are validated to make sure all components are available. If an error is detected, the build process is aborted. The build process logs the process in a log file named <PackagingInstructionsClassName>.log.
Example: "HelloWorldPackagingInstructions.log".
The name of the log file can be specified using the logFileName: attribute. Whether the build fails or succeed, it is usually a good idea to review the log.
Build Artifacts Output
The packager will generate different type of files during packaging...for example, statistics files (.es) and image files (.ic and icx).
These files are initially saved in the current working directory. At the end of the build process, the files are copied to the <baseTargetDirectory>\YYYYMMDDHHMMSS , which defaults to <nameOfAbsBuildSpecification>\YYYYMMDDHHMMSS. There are several subfolders created which store the statistics files (es) and image files (.ic and .icx). The log file is copied to <baseTargetDirectory>\YYYYMMDDHHMMSS folder.
If the AbsBuildSpecification answers false (default) to #leaveFilesInSourceDirectoryFlag, the build artifacts are deleted from the working directory after copying them to the <baseTargetDirectory>