Documentation
¶
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Comparer ¶
type Comparer struct {
}
Comparer handles comparison operations between BuildPlans
func (*Comparer) BuildPlans ¶
BuildPlans compares two BuildPlan Files for semantic equivalence.
The holos show buildplans command writes a BuildPlan File to standard output. A BuildPlan File is a yaml encoded stream of BuildPlan objects.
BuildPlan File one is equivalent to two when:
- one and two have an equal number of BuildPlan objects.
- each object in one is equivalent to exactly one unique object in two.
Two BuildPlans, before and after, are equivalent when:
- All field values in before are equivalent to the same field in after
- Both 1 and 2 apply to nested objects, recursively.
- Field f is equivalent when before.f exactly equals after.f, except for: 3.1. Objects in the spec.artifacts list may appear in any arbitrary order. 3.2. The ordering of keys does not matter.
- Backwards compatibility behavior (controlled by isBackwardsCompatible): - When false: after and before must have exactly the same fields - When true: after may have additional fields that don't exist in before (e.g., new features added in a newer version) Example: before has {name: "x", version: "1.0"} after has {name: "x", version: "1.0", newFeature: "enabled"} This comparison passes when isBackwardsCompatible=true
- Fields in before must always be present in after (regardless of backwards compatibility mode).
- List type fields with a null value are equivalent to: 6.1. null values 6.2. empty values ([]) 6.2. a missing field
A BuildPlan File is valid when:
- Two or more identical objects exist in the same file. They must be treated as unique objects when comparing BuildPlan Files
- Two objects may have the same value for the metadata.name field.
- The kind field of all objects in the file stream is "BuildPlan"
Click to show internal directories.
Click to hide internal directories.