Allow overriding variable choices via choices.d/<name>.yml

[arvind4501]

Summary

• Adds support for overriding a playbook variable's choices list without editing its metadata.obsah.yaml. If a variable declares choices in metadata, obsah will now also look for choices.d/<variable_name>.yml next to the playbook's metadata file; if present, its contents fully replace the metadata-defined choices for that variable.
• This is useful for downstream consumers (e.g. foremanctl) that need to customize choice lists (for example, a flavor variable) per deployment/distribution without forking or patching the upstream playbook's metadata.
• If no choices.d/<name>.yml file exists, behavior is unchanged — the metadata's choices are used as before.

Example

metadata.obsah.yaml:

variables:
  flavor:
    help: Base flavor to use
    choices:
      - gamma

choices.d/flavor.yml:

- alpha
- beta

Result: the flavor variable's choices become [alpha, beta], completely replacing [gamma].

Note: the override is only consulted for variables that already declare a choices key in metadata (even a placeholder value); variables without a choices key are unaffected.

Test plan

• Added tests/test_choices_directory.py with a new fixture playbook (tests/fixtures/playbooks/choices_file/) covering both the override and fallback (no-override) cases.
• Updated tests/fixtures/help.txt / help-3.12.txt golden files to include the new fixture playbook in the parser help output.
• Ran the full test suite (pytest tests/); all tests pass except pre-existing, environment-specific failures unrelated to this change (sandbox lacks permission to write to ~/.ansible/tmp).

Made with Cursor

[evgeni]

Is choices the only thing we'd ever want to override?
Clearly we do not want to override the variable name, but the description text maybe?
(Technically, overriding the parameter would also be interesting, but I'd prefer if we don't have to use that)

[arvind4501]

Is choices the only thing we'd ever want to override? Clearly we do not want to override the variable name, but the description text maybe? (Technically, overriding the parameter would also be interesting, but I'd prefer if we don't have to use that)

i have not thought about that, i think we don't want to override the options/vars which is expose by obsah. i went with choices because thats something i think could vary between distributions of foremanctl.
About the description text, i think that would be a nice addition too, but i could not think of a use case where we need that now.

[evgeni]

Yeah, right now we do not need that.

I just wonder if by explicitly calling this "choices override" we put us into a corner which we will need coordinated migration (as the paths and structure will be used in a different repository that actually declares the overrides) if we ever decide in the future we need more fields.

[ekohl]

(Technically, overriding the parameter would also be interesting, but I'd prefer if we don't have to use that)

Any thoughts on masking exposed options? I can imagine we'd have some options in upstream that shouldn't be possible in downstream.

[arvind4501]

I just wonder if by explicitly calling this "choices override" we put us into a corner which we will need coordinated migration (as the paths and structure will be used in a different repository that actually declares the overrides) if we ever decide in the future we need more fields.

yes, that's something to think about, i have not thought that far ahead but if you have suggestions about making it more general than overriding "just choices" , i would love to apply that