fix: allow List attributes to use regex parameter

[wvandeun]

Add support for List attributes to accept regex validation via parameters.regex syntax. List attributes can now use TextAttributeParameters which includes regex support.

Changes:

• Added List to parameter class mapping
• Created ListAttributeSchema with regex reconciliation
• Updated validation to allow TextAttributeParameters for List
• Added tests for List with regex parameter

Fixes #7717

Summary by CodeRabbit

• New Features

  • Introduced a new "List" attribute kind with integrated regex validation support, offering enhanced configuration options and data validation capabilities for attributes.

• Tests

  • Added comprehensive unit tests validating List attribute functionality, including regex parameter parsing, accessibility through dedicated methods, and automatic reconciliation of attribute and parameter settings.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

This pull request introduces support for List attribute kind with regex parameters. The changes add a new ListAttributeSchema class that reuses TextAttributeParameters for parameter handling. The mapping in attribute_schema_class_by_kind is extended to associate the "List" kind with the new schema. Parameter validation is relaxed to permit TextAttributeParameters with "List" kind alongside existing "Text" and "TextArea" support. A get_regex method is added to expose regex constraints from parameters. Two unit tests verify that List attributes with regex parameters are correctly parsed and that regex values reconcile properly between the attribute and its parameters.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 14.29% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: enabling List attributes to support regex parameters, which directly aligns with the core objective of the PR.
Linked Issues check	✅ Passed	The PR fully addresses issue #7717 by implementing the three required objectives: allowing List attributes to accept regex via parameters.regex, enabling successful schema loading, and maintaining backward compatibility.
Out of Scope Changes check	✅ Passed	All code changes directly support the primary objective of adding regex support to List attributes. No unrelated modifications are present in the changeset.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch wvd-20251126-fix-list-regex-parameter

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codspeed-hq]

CodSpeed Performance Report

Merging #7718 will not alter performance

_{Comparing wvd-20251126-fix-list-regex-parameter (40cc3e7) with stable (6e27404)¹}

Summary

✅ 12 untouched

Footnotes

1. No successful run was found on stable (c171357) during the generation of this report, so 6e27404 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (3)

backend/infrahub/core/schema/attribute_parameters.py (1)

14-21: Mapping List to TextAttributeParameters is consistent with the new schema usage

Hooking "List" into get_attribute_parameters_class_for_kind so it returns TextAttributeParameters lines up with ListAttributeSchema.parameters and prevents the validation error described in the issue. It also means list attributes now expose regex (and other text constraints) through parameters, which is what the new tests rely on. If, longer-term, you decide that only regex should be configurable for lists, you could consider a dedicated ListAttributeParameters subclass, but for this bugfix the current change is appropriate and cohesive with the rest of the PR.

backend/tests/unit/core/schema/test_attribute_parameters.py (1)

255-307: New List + regex tests exercise the key paths well

Both tests nicely cover the intended behavior: correctly instantiating TextAttributeParameters for kind="List", exposing regex via get_regex(), and reconciling when only parameters.regex is set. To fully mirror TextAttributeSchema semantics, you could optionally add a third test where both regex and parameters.regex are set with different values and assert that the chosen precedence for List matches Text/TextArea, but that’s not required for fixing the reported bug.

backend/infrahub/core/schema/attribute_schema.py (1)

272-296: ListAttributeSchema implementation matches the intended regex behavior; minor reuse opportunities

The new ListAttributeSchema reusing TextAttributeParameters and reconciling regex between the attribute and its parameters is consistent with TextAttributeSchema and with the new tests:

• parameters: TextAttributeParameters ensures JSON/YAML tooling sees the right parameter shape.
• reconcile_parameters correctly normalizes regex, with parameters.regex effectively taking precedence when set.
• Overriding get_regex to read from parameters matches how TextAttributeSchema exposes its final regex.

If you later want lists to support additional text-style constraints (min_length/max_length) the same way, you could factor the shared reconciliation logic into a small mixin/base class used by both Text and List schemas; conversely, if regex is the only supported constraint for lists, a brief comment or dedicated parameters type could make that intention explicit and avoid future confusion. The current implementation is still perfectly fine for this fix.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c171357 and 40cc3e7.

📒 Files selected for processing (3)

• backend/infrahub/core/schema/attribute_parameters.py (1 hunks)
• backend/infrahub/core/schema/attribute_schema.py (2 hunks)
• backend/tests/unit/core/schema/test_attribute_parameters.py (1 hunks)

🧰 Additional context used

📓 Path-based instructions (3)

backend/**/*.py

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Use Poetry for dependency management in backend Python projects

Files:

• backend/infrahub/core/schema/attribute_parameters.py
• backend/tests/unit/core/schema/test_attribute_parameters.py
• backend/infrahub/core/schema/attribute_schema.py

**/*.py

📄 CodeRabbit inference engine (.github/instructions/python-docstring.instructions.md)

**/*.py: Always use triple quotes (""") for Python docstrings
Follow Google-style docstring format for Python docstrings
Include brief one-line description in Python docstrings when applicable
Include detailed description in Python docstrings when applicable
Include Args/Parameters section without typing in Python docstrings when applicable
Include Returns section in Python docstrings when applicable
Include Raises section in Python docstrings when applicable
Include Examples section in Python docstrings when applicable

**/*.py: Use type hints for all function parameters and return values in Python
Use async def for asynchronous functions in Python
Use await for asynchronous calls in Python
Use Pydantic models for dataclasses in Python
Use ruff and mypy for type checking and validations in Python

Use ruff and mypy to validate and lint Python files

**/*.py: Use type hints for all function parameters and return values in Python code
Use async/await whenever possible; use async def for asynchronous functions and await for asynchronous calls
Use Pydantic models for dataclasses instead of plain Python dataclasses
Always use triple quotes (""") for docstrings and follow Google-style docstring format with sections: brief description, detailed description (if needed), Args/Parameters, Returns, Raises, and Examples when applicable
Use ruff and mypy for type checking and validations; run poetry run invoke format to format all Python files and poetry run invoke lint to validate formatting

Files:

• backend/infrahub/core/schema/attribute_parameters.py
• backend/tests/unit/core/schema/test_attribute_parameters.py
• backend/infrahub/core/schema/attribute_schema.py

backend/tests/**/*.py

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

backend/tests/**/*.py: Run backend tests with pytest or via invoke tasks
Place backend tests in backend/tests/ directory

Files:

• backend/tests/unit/core/schema/test_attribute_parameters.py

🧬 Code graph analysis (1)

backend/infrahub/core/schema/attribute_schema.py (2)

backend/infrahub/core/schema/attribute_parameters.py (1)

• TextAttributeParameters (29-59)

backend/infrahub/core/constants/schema.py (1)

• UpdateSupport (16-21)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Cloudflare Pages

🔇 Additional comments (1)

backend/infrahub/core/schema/attribute_schema.py (1)

126-133: Parameter validation now correctly permits TextAttributeParameters for kind="List"

Allowing TextAttributeParameters when self.kind is "List" brings validate_parameters in line with the new parameter mapping and ListAttributeSchema, preventing the previous “can’t be used as parameters for List” error. This fits the intended model without changing behavior for other kinds.

[dgarros]

I would be good to add a test to ensure that the regex is properly applied to the values in the list