Building and Packaging

Building and Packaging#

Introduction#

Building and packaging are the main development operations for Fuze and lead to generation of a FuzeID. For convenience, we will use the term “build” for any and all operations that result in new FuzeID.

What is a Build?#

A build is one type of Fuze operation that generates a FuzeID.

  • A build is, at its core, a set of any commands defined in a Build Map and executed within the context of a CBE. However, for a build to make any sense for this tool, it should produce an output to be tagged with the FuzeID.

  • A build can be the compile and linking of source code to produce a binary artifact output.

  • A build can be a complex operation of building source with external dependencies and then packaging those artifacts with other packages, artifacts, and files to produce a singular artifact.

  • A build can be a packaging operation of files that pre-exist.

Common Build Environment (CBE)#

A CBE is required for build operations. It is a container that is a 100% configuration managed, traceable, and reproducible environment. CBE’s are one of the technologies that allow Fuze to execute from any platform.

More detailed information about CBE’s can be found in the CBE Reference.

The Build Map File#

A Build Map file is the main user-generated input for the Fuze build operation. It contains all of the information for Fuze to perform a build operation, including packaging.

Detailed reference information on the build map file can be found in the Build Map Reference.

Workspace Context for Build and Package#

The following shows the workspace contexts in which the two main sections of the build map execute:

_images/fuze-build-workspace-context.png

  • All build commands, operations, and associated actions from the “build” section execute in the CBE workspace.

  • All package commands, operations, and associated actions from the “packages” section execute in the local host workspace.

Types of Builds#

Several types of builds can be generated from Fuze, and each have specific meanings and functionality. The FuzeID formats for each can be found on the FuzeID page.

Universal (or Regular)#

The most common, and the only type of build that has meaning outside of one’s own local system, is the universal (sometimes referred to as “regular”) Fuze build.

Example of Universal FuzeID:

123456-123-12345

Local#

Local builds and their packages are only available to you on your local machine.

See the Local Builds documentation for a detailed explanation.

Example of Local FuzeID:

123456L123-12345

Meaningless#

Meaningless builds do not have traceability, config management, or sharing characteristics of a universal build.

Example of Meaningless FuzeID:

123456X123-12345

What is a Package?#

A package is a collection of specified files that Fuze puts together into a single zip file.

Like with build, the packaging process is defined in the build map. The Build Map Reference Guide shows the details of the packaging section.

Workspace Context for Packaging#

As shown in the Workspace Context for Build and Package section, the packaging section of the build map executes in the context of the host machine.

Package Targets and Format#

See the Build Map Reference for detailed understanding of these fields.

Example:

internal-test-cs7-kepler-slc38.v7.11.230130-4db-7047.db

Dependencies#

Fuze enables full configuration management of build dependencies.

See the Build Map Reference for more information.

Where are My Packages?#

Warning

Packages used as dependencies must be in the FuzeDB

You must use --update-packages or --add-packages (during current build, or to add to a pre-existent build) to make a package available as a dependency.

Making packages available for both downloading and dependency import is an important operation.

Versioning#

A version is made up of two parts:

  • The human-readable part (release_version from Build Map)

  • The autogenerated FuzeID

v<release_version>.<FuzeID>

How to Build and Package#

All build functions use the --build-map option.

Arguments and Options#

See the Build Map Reference for details.

Special Target Case: Clean Target#

Including the target keyword clean invokes a special Fuze cleaning operation.

Build and Package Artifact Output#

Fuze Output File#

The purpose of this file is mainly for automation (CI tools, scripting, etc).

Fuze Temp Location (FTL)#

See more details: FTL Reference.

Build Artifacts#

At the conclusion of the build, all specified artifacts are copied from the CBE back to the user local workspace.

Packages#

Output package zip files are located in the FTL.

Log Files#

Log files are located in “logs” directory of the FTL. More information: Log Files.

Output Example#

Example workspace layout before and after build execution.

Adding Packages to the Current Building FuzeID#

Adding Packages to Current Build#

Using --add-packages with the current build attaches the created packages to current build FuzeID.

Adding Packages of Files to Pre-Existing FuzeID#

See Modifying Pre-Existent FuzeID Objects for more details.

How Target Definitions Affect FuzeIDs and Builds#

A single FuzeID is generated per Fuze build execution.

See the Build Map Reference Guide for details.

Contents