gl-features-parse incorrectly sorts features

Getting the CNAME for the following inputs returns different results:

# gl-features-parse --feature-dir ../gardenlinux/features --cname aws-gardener_fips_prod --default-version today --default-arch amd64 cname
aws-gardener_fips_prod-amd64

# gl-features-parse --feature-dir ../gardenlinux/features --cname aws-gardener_prod_fips --default-version today --default-arch amd64 cname
aws-gardener_prod_fips-amd64

# gl-features-parse --feature-dir ../gardenlinux/features --cname aws_prod-gardener_fips --default-version today --default-arch amd64 cname
aws_prod-gardener_fips-amd64

# gl-features-parse --feature-dir ../gardenlinux/features --cname _prod-gardener-aws_fips --default-version today --default-arch amd64 cname 
Traceback (most recent call last):
  File "/Users/D064507/git/gardenlinux/python-gardenlinux-lib/.venv/bin/gl-features-parse", line 6, in <module>
    sys.exit(main())
             ~~~~^^
  File "/Users/D064507/git/gardenlinux/python-gardenlinux-lib/src/gardenlinux/features/__main__.py", line 93, in main
    cname = CName(
        args.cname, arch=arch, commit_hash=commit_id_or_hash, version=version
    )
  File "/Users/D064507/git/gardenlinux/python-gardenlinux-lib/src/gardenlinux/features/cname.py", line 66, in __init__
    assert re_match, f"Not a valid GardenLinux canonical name {cname}"
           ^^^^^^^^
AssertionError: Not a valid GardenLinux canonical name _prod-gardener-aws_fips

This should not be the case. The feature sorting in the CNAME must not be depending on the input order. regardless of the order in which the input CNAME is given, the output must always have the canonical sorting.

Impact:

The following GitHub actions run on the main gardenlinux repo is failing as a result of this: https://github.com/gardenlinux/gardenlinux/actions/runs/19031355741/job/54346133990?pr=3744

Root cause appears to be that gl-features-parse blindly trusts the input cname¹, rather then the reverse_cname_base call that parse_features does² inside the builder to always go from cname -> expanded feature set -> cname in order to cleanly sever any connection between the input and output order of features.

Hi, here's the result after #248 is applied:

gl-features-parse --feature-dir ../gardenlinux/features --cname aws-gardener_prod_fips --default-version today --default-arch amd64 cname
aws-gardener_fips_prod-amd64-today-local

gl-features-parse --feature-dir ../gardenlinux/features --cname aws-gardener_prod_fips --default-version today --default-arch amd64 cname
aws-gardener_fips_prod-amd64-today-local

gl-features-parse --feature-dir ../gardenlinux/features --cname aws_prod-gardener_fips --default-version today --default-arch amd64 cname
aws-gardener_fips_prod-amd64-today-local

For gl-features-parse --feature-dir ../gardenlinux/features --cname _prod-gardener-aws_fips --default-version today --default-arch amd64 cname I would keep the exception, as (even thought it might be theoretically valid) I do not see any use case why a flag should be used for the first element of a canonical name.

Navigation Menu

Repository navigation

gl-features-parse incorrectly sorts features #244

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

gl-features-parse incorrectly sorts features #244

Description

Activity

nkraetzschmar commented on Nov 3, 2025

Footnotes

NotTheEvilOne commented on Nov 10, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions