`CName.load_from_release_file()` enforces pre-parsed cname consistency instead of treating the release file as authoritative

[nkraetzschmar]

Summary

The current flow requires constructing a CName from a cname string first and only then loading a .release file, with the loader enforcing consistency between the pre-parsed cname and the release metadata.

This approach is inherently broken for the intended use case: loading builder-generated release metadata.

The release file entries output by the builder are the canonical source of truth for the S3 uploaded metadata. Any cname parsing performed by the library is necessarily heuristic and must not be allowed to override or invalidate builder output.

Core problem

The current flow is effectively:

1. Parse a cname string using regex and implicit rules.
2. Load a release file.
3. Reject the release file if it does not match the previously inferred state.

This inverts authority. A derived interpretation of a cname string is treated as stronger than the metadata emitted by the builder.

This fails as soon as:

• The filename or caller-supplied cname differs from GARDENLINUX_CNAME
• The builder formats fields differently than the cname string parser expects

Concrete failure in the shown example

In upload_from_directory, the CName object is constructed from the artifact directory name / filename:

openstack-metal-arm64-today-local.release

This results in a pre-parsed cname that includes the commit (-local).

The release file itself, however, contains:

GARDENLINUX_CNAME=openstack-metal-arm64-today

When load_from_release_file() is called, it compares the release file’s GARDENLINUX_CNAME (parsed into a new CName instance) against the already-initialized self and fails the consistency check.

This is not an edge case. It is a direct consequence of requiring the release file to conform to a cname that was inferred earlier from the filename.

Design issue (main point)

Parsing a cname string first and then requiring the release file to match that parse is fundamentally flawed.

The release file entries output by the builder are the canonical source of truth for the S3 uploaded metadata.
Regex-based cname parsing in the library is secondary and must never veto or reinterpret builder metadata.

The loader should populate fields from the release file directly, without attempting to validate them against a previously parsed cname.

Additional FYI

• There is a small typo/inconsistency around _feature_platform_cached vs _feature_platforms_cached, which can lead to attribute errors before a release file is loaded.

Expected direction

• Allow constructing a CName directly from a release file, without requiring an initial cname string.
• Treat the release file as authoritative and load its fields verbatim.
• If validation exists, it should only check internal consistency within the release file itself, not against caller-supplied or heuristically parsed input.

This aligns the implementation with how the metadata is produced and should be consumed in practice.

[NotTheEvilOne]

While #305 allows support for broken release files I do not agree with the problem description of the original author:

• If for an existing Garden Linux canonical name instance additional (cache) data is loaded from a file consistency checks as far as feasible are absolutely required. Otherwise any unrelated file could overwrite e.g. features while something totally different was expected based on a cname given.
• A new method CName.new_from_release_file() was added to create new instances without a given Garden Linux canonical name.
• The cname openstack-metal-arm64-today misses the commit ID (local) and is therefore not valid. A commit ID is the mandatory final part of a Garden Linux canonical name. Otherwise no distinction is possible to correctly interpret what a flag, an architecture, a version or a commit ID would be.
• As the *.release file fortunately contains commit hashes (or local if build without a hash) we can workaround current files not conforming to the expected format.