The FuzeID

Introduction

The FuzeID is heart of Fuze’s configuration management. FuzeID’s have a structure that was created to provide both human readability and understanding as well as guaranteed uniqueness.

FuzeID Structure

The following is the structure of a FuzeID:

YYMMDDZTTT-XXXXX

Where,

  • YYMMDD: is the date on which FuzeID was created

    • YY is in range [18: ]

    • MM is in range [1:12]

    • DD is in range [1:31])

  • Z: is the indicator field: [- | L | C | X], indicates a universal, local, child, or meaningless FuzeID

  • TTT: is the minute of the day on which the FuzeID was created, in hex format with range [000:59F] (0-1439)

  • XXXXX: is a hash value to guarantee uniqueness

Indicator Field

The 7th character from the left is the Indicator Field. The indicator field defines the type of FuzeID. See below for a detailed description of the types of FuzeID’s. The values for indicator field are:

  • - : Universal FuzeID

  • L : Local FuzeID

  • C : Child FuzeID

  • X : Meaningless FuzeID

Examples

Universal FuzeID

20190124-2d7-12345

Local FuzeID

20190124L23f-56789

Child FuzeID

20190124C23f-56789

Meaningless FuzeID

20190124X23f-56789

When is a FuzeID Generated?

A FuzeID is generated for the following types of operations:

  • Build : The argument --build-map is the key required to perform a build operation and will always generate a FuzeID. See Building for more information.

  • Assign FuzeID : The argument --assign-fuzeid is a method to assign a FuzeID to any digital file(s).

What Operations do NOT Generate a FuzeID?

The following types of operations do NOT generate a new FuzeID:

  • Releasing/deployment

  • Delivery

  • Searching

  • Downloading packages

  • Creating or recreating workspaces

  • Database and workspace cleaning operations

What Does FuzeID Tell Me?

With a FuzeID, you can find out the following types of information:

  • How was it built?

  • What source commitID’s were used?

  • What were the dependencies and the versions of those dependencies?

  • Was this released?

  • If it was released, what is the version?

  • Has this been sent anywhere outside the company?

  • Who generated the build?

  • What targets were built at the same time?

  • What packages are included with the build?

Type of FuzeID (Indicator Field Explained)

This section explains the various types of FuzeID’s that can be generated.

Warning

Local and Meaningless FuzeID’s may NOT be deployed/released.

Universal

Universal FuzeID’s are generated for most Fuze build operations. A universal FuzeID is known to the entire Fuze world, and is guaranteed globally unique. It can be shared amongst everyone.

It may be used for all Fuze operations, including:

  • Searching

  • Downloading packages

  • Releasing

  • Delivering

  • Universal and shared dependencies

  • Updating with new packages, files, etc

Local

The --local use case creates a local FuzeID that is only known to the local host system. Local FuzeID’s adhere to all of the formats, rules, and metadata contents of a universal FuzeID. The difference is simply that it is NOT valid nor known outside the local system.

Local FuzeID’s may be used as local build dependencies and can have the packages updated, but are not available for:

  • Searching

  • Downloading packages

  • Releasing

  • Delivering

  • Shared dependencies outside of the local system

Child

A child FuzeID has a necessary dependence upon a particular universal FuzeID. A child FuzeID is created when an operation is performed on the contents of a previously built package, but did not require a new Fuze build. For example, editing a binary code image file post-build (to modify tuning parameters, etc) will produce a child FuzeID.

A child FuzeID contains the relationship designation to its parent universal FuzeID in the FuzeDB metadata.

Child FuzeID’s may be used in all of the same operations as universal FuzeID’s.

Meaningless

A meaningless FuzeID is generated when a build cannot be guaranteed to be repeatable or put under configuration management. The most common situation that results in a meaningless FuzeID is a build with uncommitted changes in the source repository. When building, Fuze will determine the state of the local source code in relation to the repository. If there are uncommitted changes, the user may still build, but Fuze cannot create a FuzeDB entry under configuration control. The FuzeID is generated, but it has no meaning to the Fuze universe.

Meaningless FuzeID’s cannot be used for any other Fuze operations.